Interface testing method, electronic device and computer readable storage medium

Abstract

The present invention provides an interface testing method, an electronic device and a computer-readable storage medium, the method comprising: determining a log element, determining an interface log of each interface according to the data of the log element; obtaining the data of the log element of each interface log at a preset time interval to generate a new interface log, performing equivalence class merging and filtering processing on the new interface log and the corresponding historical interface log to obtain log data; comparing each specification definition with the corresponding log data to generate an intermediate representation; checking the intermediate representation to determine and filter out the problem interface in all interfaces; modifying the specification definition of the problem interface according to the intermediate representation, and testing the problem interface according to the modified specification definition. This scheme ensures the availability of test cases by standardizing the format of the interface log. The problem interface is determined by using the intermediate representation, and the interface behavior is controlled by quantifiable indicators, thereby ensuring the test integrity and interface consistency.

Description

Technical Field

[0001] The present invention relates to the technical field of interface testing, and in particular to an interface testing method, electronic equipment and a computer-readable storage medium. Background Art

[0002] The Application Programming Interface (API) is a medium for software interaction, and its interface document becomes a contract for software interaction. However, since there are often differences between the interface document and the backend interface code during software delivery, how to ensure the consistency of the contract has become a common concern. Currently known solutions can ensure the consistency of the contract through log-driven interface automation testing, that is, the logs of the production environment are cleaned and imported into the database, and the consistency with the expected interface is judged based on the interface log data.

[0003] The existing interface testing driven by logs only reuses the interface logs generated by the tester to reproduce the behavior of the interface, thereby performing some simple compliance checks on the interface. There are no detailed quantifiable indicators to regulate the behavior of the interface and guide the tester to conduct complete regression testing, making it difficult to ensure the consistency of the interface with its documentation and the availability of the interface artifacts automatically generated by the documentation. Summary of the invention

[0004] The purpose of the present invention is to solve the problem in the prior art that the integrity of the test is difficult to ensure during interface testing, which leads to low consistency of the interface and its products.

[0005] To solve the above problems, an embodiment of the present invention discloses a method for testing an interface, comprising:

[0006] S1: Determine the log elements to be collected in the interface log corresponding to the interface, obtain the data of the log elements of the interface log corresponding to each interface in all interfaces, and determine the interface log of each interface according to the data of the log elements;

[0007] S2: acquiring data of log elements of each interface log at a preset time interval to generate a new interface log, and performing equivalence class merging and filtering processing on the new interface log and the corresponding historical interface log to obtain log data;

[0008] S3: Obtain specification definitions of each interface, and compare each specification definition with corresponding log data to generate an intermediate representation corresponding to each interface;

[0009] S4: Check each intermediate representation to identify problematic interfaces among all interfaces, and filter the problematic interfaces;

[0010] S5: Modify the specification definition of the problem interface according to the intermediate representation, and test the problem interface according to the modified specification definition.

[0011] By adopting the above solution, the formats of interface log collection and reporting are unified by determining log elements, thus ensuring the availability of test cases. In addition, through the measurable indicator system of intermediate representation and problem interface, the quality of each interface can be observed intuitively, and the interface behavior can be standardized and controlled through quantifiable indicators, so that the integrity of the test is guaranteed and the consistency of the interface and its products is guaranteed.

[0012] According to another specific embodiment of the present invention, the interface testing method disclosed in the embodiment of the present invention is a contract-based interface testing method; and, each specification definition is compared with the corresponding log data to generate an intermediate representation corresponding to each interface, including: each specification definition is compared with the corresponding log data to generate an intermediate representation of the contract test corresponding to each interface; and, each intermediate representation is checked, including: using an access control system to check the intermediate representation of each contract test.

[0013] The above solution uses a contract-based interface testing method, detects inconsistent interface documents through contract testing specifications, and uses the contract testing specifications as the baseline of the access control system, making the consistency of the front-end interface documents and the back-end interface codes better. That is, by using contract testing, the interface behavior is regulated and controlled through quantifiable indicators, the integrity of the test is guaranteed, and the consistency of the interface and its products is guaranteed.

[0014] According to another specific embodiment of the present invention, in the interface testing method disclosed in the embodiment of the present invention, in step S1, the log elements include: interface name or interface unique identifier, interface request method (Method), header (Header) and body (Body) of the interface request response, interface request time, and a unique identification code (UUID) of the interface request.

[0015] By adopting the above solution, the formats of interface log collection and reporting are unified by determining the log elements, thus ensuring the availability of test cases.

[0016] According to another specific embodiment of the present invention, the interface testing method disclosed in the embodiment of the present invention, in step S2, the data of the log elements of each interface log is obtained at a preset time interval to generate a new interface log, including: using the open source project scheduled task to obtain the log elements of each interface log at a preset time interval to generate a new interface log; and, respectively, the new interface logs and the corresponding interface logs are subjected to equivalence class merging and filtering processing, including: respectively merging the new interface logs and the data corresponding to the corresponding interface logs; filtering the merged data using the equivalence class partitioning method; and, before obtaining the data of the log elements of each interface log at a preset time interval to generate a new interface log, it also includes: establishing a persistent warehouse; after obtaining the log data, it also includes: storing the log data of each interface in the persistent warehouse; and, in step S3, obtaining the specification definition of each interface, and comparing each specification definition with the corresponding log data, including: obtaining the specification definition of each interface, obtaining the log data of each interface from the persistent warehouse, and comparing each specification definition with the corresponding log data.

[0017] By adopting the above scheme, by merging the new interface log and the old interface log, and filtering the merged data using the equivalence class division method, the replacement and addition of the interface log equivalence class are realized, and the update and incremental synchronization are realized. In addition, by establishing a persistent warehouse to store the log data in a unified manner, the possibility of data loss is reduced. By storing the log data in a unified manner in the persistent warehouse, there is no need to search for data from various locations when calling the data later, but to directly retrieve and call from the persistent warehouse, which improves the efficiency of calling data.

[0018] According to another specific embodiment of the present invention, the interface testing method disclosed in the embodiment of the present invention, after step S2, further includes:

[0019] S2': For the erroneous interfaces obtained through filtering, screen out the interfaces that need to be destructively changed and have been modified for backend services, review the screened interfaces and perform equivalent class offline processing.

[0020] By adopting the above solution, after filtering, the error interface and its equivalent class interfaces are taken offline, and the error interface is eliminated, which can make the interface test process more stable and the result more accurate.

[0021] According to another specific embodiment of the present invention, in the interface testing method disclosed in the embodiment of the present invention, in step S3, the intermediate representation includes error type indicators of each interface; wherein the error type indicators include missing required fields, field type errors, and field case errors.

[0022] By adopting the above scheme, the error type index of each interface is determined by generating an intermediate representation. In the subsequent test process, the interfaces with error type indicators can be filtered, thereby making the interface test process more stable and the test results more accurate.

[0023] According to another specific embodiment of the present invention, the interface testing method disclosed in the embodiment of the present invention, in step S3, when generating the intermediate representation corresponding to each interface, further includes: performing interface coverage detection and field coverage detection on each interface; in step S4, the problem interface is:

[0024] Interfaces with insufficient coverage obtained through interface coverage detection, interfaces with insufficient coverage obtained through field coverage detection, or interfaces with document errors; and, in step S4, filtering problematic interfaces, including: preventing problematic interfaces from being released online.

[0025] By adopting the above scheme, the problem interface is set as an interface that meets any of the following conditions: an interface with insufficient coverage obtained through interface coverage detection, an interface with insufficient coverage obtained through field coverage detection, and an interface with document errors. These problems and errors are those that can affect the test integrity and interface consistency. Filtering such problem interfaces can avoid the test results, integrity, and interface consistency being affected due to interface problems, and there is no need to detect other errors, which reduces detection efficiency. In addition, by preventing the problem interface from being released online, the interfaces that pass the test can be interfaces that meet the contract consistency, ensuring the accuracy and stability of the test.

[0026] According to another specific embodiment of the present invention, the interface testing method disclosed in the embodiment of the present invention, after step S5, also includes: screening out interfaces that cannot be regression tested from the remaining interfaces; generating a whitelist based on the interfaces that cannot be regression tested using a regularization method; wherein the whitelist is a whitelist that supports timed offline; and testing the remaining interfaces according to the whitelist and the corresponding specification definitions.

[0027] The above solution provides a regular expression-based whitelist mechanism for the problem that some interfaces are difficult to regression test. In this way, interfaces that are difficult to regression test can be added to the whitelist to facilitate testing. The whitelist supports scheduled offline and is also convenient for online control of the interface.

[0028] An embodiment of the present invention further discloses an electronic device, comprising: a memory for storing a computer program, the computer program comprising program instructions; a processor for executing the program instructions so that the electronic device executes the interface testing method described in any of the above embodiments.

[0029] An embodiment of the present invention further discloses a computer-readable storage medium storing a computer program. The computer program includes program instructions. The program instructions are executed by an electronic device to enable the electronic device to execute the interface testing method described in any of the above embodiments.

[0030] The beneficial effects of the present invention are:

[0031] The interface testing method provided by the present invention unifies the formats of interface log collection and reporting by determining log elements, thereby ensuring the availability of test cases. Moreover, through the measurable indicator system of intermediate representation and problem interface, the quality of each interface can be observed intuitively, and the interface behavior can be standardized and controlled through quantifiable indicators, so that the integrity of the test is guaranteed, and the consistency of the interface and its products is guaranteed. Further, a contract-based interface testing method is adopted, and the problem of inconsistent interface documents is detected through the contract testing specification, and the contract testing specification is used as the baseline of the access control system, so that the consistency of the front-end interface documents and the back-end interface codes is better. Furthermore, through a determined and complete access control system, any interface that may be wrong can be omitted, thereby improving the accuracy and reliability of the test. The persistence solution based on the open source distributed version control system and the continuous integration (CI) and continuous delivery (CD) systems are used to make the system lighter. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 It is a flowchart of a method for testing an interface provided by an embodiment of the present invention;

[0033] Figure 2 It is a CI flow chart of the interface testing method provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0034] The following specific embodiments illustrate the implementation of the present invention, and those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. Although the description of the present invention will be introduced in conjunction with the preferred embodiment, this does not mean that the features of this invention are limited to this implementation. On the contrary, the purpose of introducing the invention in conjunction with the implementation is to cover other options or modifications that may extend based on the claims of the present invention. In order to provide a deep understanding of the present invention, the following description will include many specific details. The present invention can also be implemented without using these details. In addition, in order to avoid confusion or blurring the focus of the present invention, some specific details will be omitted in the description. It should be noted that the embodiments of the present invention and the features in the embodiments can be combined with each other without conflict.

[0035] It should be noted that in this specification, similar reference numerals and letters denote similar items in the following drawings, and therefore, once an item is defined in one drawing, it does not need to be further defined and explained in the subsequent drawings.

[0036] In the description of this embodiment, it should be noted that the terms "upper", "lower", "inner", "bottom", etc. indicate orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, or are the orientations or positional relationships in which the inventive product is usually placed when used. They are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on the present invention.

[0037] The terms “first”, “second”, etc. are only used for distinguishing descriptions and should not be understood as indicating or implying relative importance.

[0038] In the description of this embodiment, it is also necessary to explain that, unless otherwise clearly specified and limited, the terms "set", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be indirectly connected through an intermediate medium, or it can be the internal communication of two components. For ordinary technicians in this field, the specific meanings of the above terms in this embodiment can be understood according to specific circumstances.

[0039] In order to make the objectives, technical solutions and advantages of the present invention more clear, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings.

[0040] In order to solve the problem in the prior art that the integrity of the test is difficult to ensure during the interface test, resulting in low consistency of the interface and its products, an embodiment of the present invention provides an interface testing method. Specifically, refer to Figure 1 The interface testing method provided by the present invention comprises the following steps:

[0041] S1: Determine the log elements to be collected in the interface log corresponding to the interface, obtain the data of the log elements of the interface log corresponding to each interface in all interfaces, and determine the interface log of each interface according to the data of the log elements;

[0042] S2: acquiring data of log elements of each interface log at a preset time interval to generate a new interface log, and performing equivalence class merging and filtering processing on the new interface log and the corresponding historical interface log to obtain log data;

[0043] S3: Obtain specification definitions of each interface, and compare each specification definition with corresponding log data to generate an intermediate representation corresponding to each interface;

[0044] S4: Check each intermediate representation to identify problematic interfaces among all interfaces, and filter the problematic interfaces;

[0045] S5: Modify the specification definition of the problem interface according to the intermediate representation, and test the problem interface according to the modified specification definition.

[0046] Furthermore, in the test method of the interface according to the present invention, the test method can test multiple interfaces. Among them, each interface corresponds to multiple interface logs, and the multiple interface logs correspond to different moments, that is, there are new interface logs and historical interface logs. Each interface log contains multiple log elements, and multiple interface logs corresponding to the same interface have the same log elements. Each interface also has a corresponding specification definition.

[0047] Specifically, in step S1, the data of the log element refers to the value of each log element. For example, when the log element is a unique identification code for an interface request, the log element data can be 550e8400-e29b-41d4-a716-446655440000. In step S2, the preset time interval can be set arbitrarily, and can be a time interval of 5 milliseconds, 8 seconds, or even 30 minutes, 1.5 hours, etc., and those skilled in the art can comprehensively determine it according to the update time of the data and the amount of data. The interface log consists of the data of the log element and other fixed elements. In addition, the log collection method can be a push mode or a pull mode, as long as the format of the log collection is followed. In step S2, the historical interface log is the interface log in step S1. The log data is the data about the interface log obtained after the equivalence class merging and filtering process is performed on the new interface log and the historical interface log. In step S3, the specification definition of the interface is pre-set, and each interface has a corresponding specification definition. In step S4, the intermediate representation is checked by the policy engine.

[0048] By adopting the above solution, the formats of interface log collection and reporting are unified by determining log elements, thus ensuring the availability of test cases. In addition, through the measurable indicator system of intermediate representation and problem interface, the quality of each interface can be observed intuitively, and the interface behavior can be standardized and controlled through quantifiable indicators, so that the integrity of the test is guaranteed and the consistency of the interface and its products is guaranteed.

[0049] Further, in the test method of the interface according to the present invention, the test method of the interface is a contract-based interface test method. And, each specification definition is compared with the corresponding log data to generate an intermediate representation corresponding to each interface, including: each specification definition is compared with the corresponding log data to generate an intermediate representation corresponding to the contract test of each interface. And, each intermediate representation is checked, including: using an access control system to check the intermediate representation of each contract test. Specifically, the access control system is a system that relies on certain strategies to determine whether specific external data can be allowed to enter the internal system, thereby ensuring the availability of internal data.

[0050] Furthermore, in the test method of the interface according to the present invention, the contract in the contract-based interface test refers to a consumer-driven contract, which divides the service into the consumer side and the producer side. The core idea of ​​consumer-driven contract testing is to start from the perspective of consumer business implementation, and the consumer himself will define the required data format and interaction details, and drive the generation of a contract document. Then the producer implements his own logic according to the contract document and continuously verifies it in a continuous integration environment. With such steps, due to the use of a contract-based interface testing method, the inconsistency of the interface document is detected through the contract testing specification, and the contract testing specification is used as the baseline of the access control system, so that the consistency of the front-end interface document and the back-end interface code is better.

[0051] Further, in the test method of the interface according to the present invention, in step S1, the log elements include: interface name or interface unique identifier, interface request method (Method), header (Header) and body (Body) of the interface request response, interface request time, and unique identification code (UUID) of the interface request. It should be noted that the present embodiment only schematically lists several log elements. In fact, those skilled in the art can add other log elements according to the test type and required data, and the present specific embodiment does not limit this. It should also be noted that the interface corresponding to the log element in the present specific embodiment specifically refers to the HTTP interface in the application program interface. Furthermore, with such a step, by determining the log element, the format of interface log collection and reporting is unified, and the availability of test cases is guaranteed.

[0052] Further, in the test method of the interface according to the present invention, in step S2, the data of the log elements of each interface log is obtained at preset time intervals to generate a new interface log, including: using an open source project scheduled task to obtain the log elements of each interface log at preset time intervals to generate a new interface log. And, each new interface log and each corresponding interface log are respectively subjected to equivalence class merging and filtering processing, including: merging the data corresponding to each new interface log and each corresponding interface log; filtering each merged data using an equivalence class partitioning method. Specifically, in this specific implementation, through a GitLab CI (Continuous Integration, CI) scheduled task, that is, at regular intervals, the latest collected log is merged with the existing data and then filtered through equivalence class partitioning.

[0053] Furthermore, with such steps, the replacement and increase of the interface log equivalence class are realized, and the update and increment synchronization are realized. More specifically, the equivalence class division method refers to classifying the data corresponding to each interface log according to different inputs, and dividing the data corresponding to each interface log into a valid equivalence class and an invalid equivalence class, and testing. After the test is completed, harmful information can be filtered according to the preset filtering conditions. It should be noted that the equivalence class division conditions can be determined comprehensively according to the type of interface and the data corresponding to the interface log, and this specific implementation method does not limit this. When filtering, those skilled in the art can also determine the filtering conditions according to actual needs, and the filtering conditions can be a specific IP address or a specific URL, and this specific implementation method does not limit this.

[0054] Furthermore, in the test method of the interface according to the present invention, before obtaining the data of the log elements of each interface log at a preset time interval to generate a new interface log, it also includes: establishing a persistent warehouse. And, after obtaining the log data, it also includes: storing the log data of each interface in the persistent warehouse. That is to say, in this specific implementation, it is necessary to establish a persistent warehouse (Git warehouse) to store the log data. With such a method, the log data is uniformly stored by establishing a persistent warehouse, which reduces the possibility of data loss. Further, in the test method of the interface according to the present invention, in step S3, the specification definition of each interface is obtained, and each specification definition is compared with the corresponding log data, including: obtaining the specification definition of each interface, obtaining the log data of each interface from the persistent warehouse, and comparing each specification definition with the corresponding log data. With such a step, the log data is uniformly stored in the persistent warehouse, and when calling the data later, there is no need to search for data from various locations, but directly retrieve and call from the persistent warehouse, which improves the efficiency of calling data.

[0055] More specifically, in this specific implementation, the data of the log elements of each interface log is obtained at a preset time interval to generate a new interface log in the following manner: First, the log is collected according to the time slice in the manner of a scheduled task. In this way, the real-time nature of the data is guaranteed and the problem of reduced collection efficiency due to the long time span of the log is avoided. Secondly, the current collection time is persisted in the warehouse at the same time during each collection. In this way, repeated collection is avoided and data compensation is convenient after the scheduled task fails. After that, the equivalence class is divided according to the set of all field names and field types parsed from the body of an interface log request response. This facilitates the verification of field names and types, wherein the nested fields are flattened according to the hierarchical relationship of the fields as the path name of the field; for example, here the ".N" mark is added to the path for the array, and the "." mark is added to the path for the structure object. In addition, for multiple interface logs contained in the same equivalence class, only the one with the latest request time is taken for persistence for storage and query.

[0056] Furthermore, in the test method of the interface according to the present invention, after step S2, it also includes: S2': for the erroneous interfaces obtained through filtering, screen out the interfaces that need to be destructively modified and have been modified by the backend service, review the screened interfaces and perform equivalence class offline processing. That is to say, after step S2, for the erroneous interfaces obtained through filtering in step S2, which need to be destructively modified and have been modified by the backend service, support the offline of the equivalence class through regular matching after review, to ensure the consistency of log data and backend services, thereby ensuring the stability of the system.

[0057] Further, in the test method of the interface according to the present invention, in step S3, the intermediate representation includes the error type indicators of each interface. Among them, the error type indicators include the missing of required fields, field type errors, and field case errors. Specifically, the missing of required fields means that there is no required field defined in the document in the log corresponding to the current interface and it is successfully called; the field type error means that the type of the corresponding field in the gateway log corresponding to the current interface is inconsistent with the definition in the document; the field case error means that the case of the corresponding field in the gateway log corresponding to the current interface is inconsistent with the definition in the document. With such a step, the error type indicators of each interface are determined by generating an intermediate representation. In the process of subsequent testing, the interfaces with error type indicators can be filtered, thereby making the interface testing process more stable and the test results more accurate. It should be understood that this embodiment only schematically lists the interface error type indicators including the above types. In fact, those skilled in the art can also set other error type indicators according to the interface type and in combination with the specific circumstances encountered during the test process.

[0058] Further, in the test method of the interface according to the present invention, in step S3, when generating the intermediate representation corresponding to each interface, it also includes: performing interface coverage detection and field coverage detection on each interface. Specifically, interface coverage detection refers to performing coverage detection on all interfaces displayed on the official website; field coverage detection refers to performing field-level coverage detection on covered interfaces. In other words, when generating the intermediate representation, coverage indicator analysis is also included. Of course, this specific implementation only schematically lists the coverage indicators including interface coverage and field coverage, and those skilled in the art can increase code coverage or other coverage indicators according to actual needs.

[0059] Further, in the test method of the interface according to the present invention, in step S4, the problem interface is: an interface with insufficient coverage obtained by interface coverage detection, an interface with insufficient coverage obtained by field coverage detection, or an interface with document errors. That is to say, in this specific implementation, the interface that meets any of the conditions of the interface with insufficient coverage obtained by interface coverage detection, the interface with insufficient coverage obtained by field coverage detection, and the interface with document errors will be filtered. With such a step, the problem interface is set to an interface that meets any of the conditions of the interface with insufficient coverage obtained by interface coverage detection, the interface with insufficient coverage obtained by field coverage detection, and the interface with document errors. These problems and errors are problems and errors that can affect the integrity of the test and the consistency of the interface. Filtering such problem interfaces can avoid the test results, integrity and consistency of the interface being affected due to problems with the interface, and there is no need to detect other errors, which reduces the detection efficiency.

[0060] Furthermore, in the test method of the interface according to the present invention, in step S4, filtering the problematic interfaces includes: preventing the problematic interfaces from being released online. With such a step, by preventing the problematic interfaces from being released online, the interfaces that pass the test can be interfaces that meet the contract consistency, thereby ensuring the accuracy and stability of the test.

[0061] Furthermore, in a preferred embodiment of the present invention, errors and coverage issues are also displayed in layers in the intermediate representation of the contract test. The layers of the layered display may include field level, interface level and product level. Moreover, through the access control of the policy engine with regular matching, interfaces with insufficient coverage or document errors are filtered out, and the corresponding interfaces are prevented from being released online. In addition, a front-end display page based on the intermediate representation of the contract test is also provided, which is convenient for more intuitive viewing of the quality of the interface.

[0062] Further, in the test method of the interface according to the present invention, after step S5, it also includes: screening out interfaces that cannot be regression tested from the remaining interfaces; generating a whitelist using a regularization method based on the interfaces that cannot be regression tested; and testing the remaining interfaces according to the whitelist and the corresponding specification definition. Among them, the whitelist is a whitelist that supports timed offline. With such steps, a regularization-based whitelist mechanism is provided for the problem that some interfaces are difficult to regression test. In this way, adding interfaces that are difficult to regression test to the whitelist can facilitate testing, and the whitelist supports timed offline, which is also convenient for online control of the interface. Specifically, in this specific implementation, for the problem that some existing interfaces are difficult to regression test, the specific details of providing a regularization-based whitelist mechanism are as follows: whitelist classification information includes products to be offline, interfaces to be offline, environment restrictions, and product restrictions. The dimensions of whitelist rules include product-level rules, interface-level rules, and path name rules for request and response fields. The field path names are the same as those used to divide equivalence classes. All rules use regular matching and use the wildcard percent sign (%) to replace zero or more characters for easy writing.

[0063] Next, refer to Figure 2 This paper describes a specific interface testing method. This method uses contract testing as the baseline of the access control system to ensure the consistency of the interface and the availability of its products. The specific steps of this method are:

[0064] First, define the format of interface log collection, which includes the following elements for the HTTP interface in the application interface: interface name or interface unique identifier, interface request method (Method), interface request response header (Header) and body (Body), interface request time, and interface request unique identifier (UUID).

[0065] Secondly, build the interface log Git repository. Through the CI scheduled task of the Git repository, merge the latest collected logs with the existing data at regular intervals, and store them in the warehouse after filtering through equivalence class division ( Figure 2 Persistent storage in the ), by collecting the latest logs to replace and add equivalent classes, the update and incremental synchronization of interface logs are realized. The specific details are as follows:

[0066] (1) Collecting logs in time slices in the form of scheduled tasks ensures a certain degree of real-time data and avoids the problem of reduced collection efficiency due to the long time span of logs;

[0067] (2) The current collection time is persisted in the warehouse each time the data is collected to avoid repeated collection and facilitate data compensation after the scheduled task fails;

[0068] (3) The equivalence class is divided according to the set of all field names and field types parsed from the body of an interface log request response, so as to facilitate the verification of field names and types. The nested fields are flattened according to the hierarchical relationship of the fields as the path name of the field; for example, here the path for arrays will be marked with ".N", and the path for structure objects will be marked with ".". In addition, for multiple interface logs contained in the same equivalence class, only the one with the latest request time is taken for persistence for storage and query.

[0069] Afterwards, for the error interfaces obtained after filtering, those that require destructive changes and have already been modified in the backend services, support is provided for taking the equivalent classes offline through regular matching after review, to ensure the consistency of log data and backend services, thereby ensuring the stability of the system.

[0070] Next, the log data is compared with the interface specification definition to generate a contract test intermediate representation, which contains indicators corresponding to various error types:

[0071] The first one is that the required fields are missing, that is, the required fields defined in the document are not present in the log corresponding to the current interface and the call is successful;

[0072] The second type is a field type error, that is, the type of the corresponding field in the gateway log corresponding to the current interface is inconsistent with that defined in the document;

[0073] The third type is the case error of the field, that is, the case of the corresponding field in the gateway log corresponding to the current interface is inconsistent with that defined in the document.

[0074] Afterwards, when generating the intermediate representation of the contract test, coverage indicator analysis is also included, including interface coverage analysis, that is, coverage detection for all interfaces displayed on the official website, and field coverage analysis, that is, field-level coverage detection for covered interfaces.

[0075] Afterwards, the errors and coverage issues are displayed in layers in the contract test intermediate representation, including field level, interface level and product level. After access control by the regular matching policy engine, interfaces with insufficient coverage or document errors are filtered out, and the corresponding interfaces are prevented from being released online. In addition, a front-end display page based on the contract test intermediate representation is also provided to facilitate a more intuitive view of the interface quality.

[0076] Afterwards, for the problem that some existing interfaces are difficult to regression test, a whitelist mechanism based on regular expressions is provided. The whitelist supports scheduled offline. The specific details are as follows: Whitelist classification information: products to be offline, interfaces to be offline, environment restrictions, and products restrictions. The dimensions of whitelist rules include product-level rules, interface-level rules, and path name rules for request and response fields. The field path name is the same as that used when dividing equivalence classes. All rules use regular matching and use the wildcard percent sign (%) to replace zero or more characters for easy writing.

[0077] This testing method can intuitively observe the quality of each interface through a measurable indicator system. It does not miss any interface that may have errors through a definite and complete access control system. It uses a Git-based persistence solution and CI / CD system to make the system lighter.

[0078] Based on the above interface testing method, this specific embodiment also provides an electronic device. The electronic device includes a memory for storing a computer program, the computer program includes program instructions; a processor for executing the program instructions so that the electronic device executes the interface testing method described in the above embodiment. Further, in the electronic device according to the present invention, those skilled in the art can select the memory and the processor according to actual needs.

[0079] Based on the above interface testing method, this specific embodiment also provides a computer-readable storage medium, which stores a computer program. The computer program includes program instructions, and the program instructions are executed by an electronic device to enable the electronic device to execute the interface testing method described in the above embodiment.

[0080] Although the present invention has been illustrated and described with reference to certain preferred embodiments of the present invention, it should be understood by those skilled in the art that the above is a further detailed description of the present invention in conjunction with specific embodiments, and it cannot be determined that the specific implementation of the present invention is limited to these descriptions. Those skilled in the art may make various changes in form and details, including making several simple deductions or substitutions, without departing from the spirit and scope of the present invention.

Claims

1. A method for testing an interface. It is characterized in that The interface testing method is a contract-based interface testing method, including: S1: Determine the log elements to be collected in the interface log corresponding to the interface, obtain the data of the log elements of the interface log corresponding to each of the interfaces in all interfaces, and determine the interface log of each of the interfaces according to the data of the log elements; S2: acquiring data of log elements of each of the interface logs at a preset time interval to generate a new interface log, and performing equivalence class merging and filtering processing on the new interface log and the corresponding historical interface log to obtain log data; S3: Obtaining specification definitions of each of the interfaces, and comparing each of the specification definitions with the corresponding log data to generate an intermediate representation corresponding to the contract test of each of the interfaces, wherein the intermediate representation includes an error type indicator of each interface; S4: using an admission control system to check the intermediate representation of each of the contract tests to determine problematic interfaces among all the interfaces, and filtering the problematic interfaces; S5: Modify the specification definition of the problematic interface according to the intermediate representation, and test the problematic interface according to the modified specification definition.

2. The method for testing an interface as claimed in claim 1, It is characterized in that In step S1, the log elements include: Interface name or interface unique identifier, interface request method, interface request response header and body, interface request time, and interface request unique identifier.

3. The method for testing an interface as claimed in claim 1, It is characterized in that In the step S2, the data of the log elements of each of the interface logs are obtained at a preset time interval to generate a new interface log, including: Using an open source project scheduled task to obtain log elements of each of the interface logs at a preset time interval to generate a new interface log; and The new interface log and the corresponding historical interface log are respectively subjected to equivalence class merging and filtering processing, including: Merging the new interface log and the data corresponding to the corresponding historical interface log respectively; Filter the merged data using the equivalence classification method; and Before acquiring the data of the log elements of each of the interface logs at a preset time interval to generate a new interface log, the method further includes: Establish a persistent warehouse; After obtaining the log data, it also includes: Storing the log data of each interface in the persistent repository; and In the step S3, the specification definition of each interface is obtained, and each specification definition is compared with the corresponding log data, including: Obtain specification definitions of each of the interfaces, obtain the log data of each of the interfaces from the persistent repository, and compare each of the specification definitions with the corresponding log data.

4. The method for testing an interface as claimed in claim 1, It is characterized in that After step S2, the method further includes: S2': for the erroneous interfaces obtained through the filtering process, screen out the interfaces that need to be destructively modified and have undergone backend service modification, review the screened interfaces and perform equivalent class offline processing.

5. The method for testing an interface as claimed in claim 1, It is characterized in that In step S3, the error type indicators include missing required fields, incorrect field types, and incorrect field case.

6. The method for testing an interface as claimed in claim 1, It is characterized in that In the step S3, when generating the intermediate representation corresponding to each of the interfaces, it also includes: Performing interface coverage detection and field coverage detection on each of the interfaces; In step S4, the problem interface is: interfaces with insufficient coverage as determined by the interface coverage test, interfaces with insufficient coverage as determined by the field coverage test, or interfaces with document errors; and In the step S4, filtering the problematic interface includes: Prevent the problematic interface from being released online.

7. The method for testing an interface as claimed in claim 1, It is characterized in that After step S5, the method further includes: Screening out interfaces that cannot be regression tested from the remaining interfaces; Generate a whitelist using a regularization method based on the interface that cannot be regression tested; wherein the whitelist is a whitelist that supports scheduled offline; The remaining interfaces are tested according to the whitelist and the corresponding specification definitions.

8. An electronic device, It is characterized in that include: A memory for storing a computer program, wherein the computer program includes program instructions; A processor is used to execute the program instructions so that the electronic device executes the interface testing method according to any one of claims 1-7.

9. A computer-readable storage medium, It is characterized in that The computer-readable storage medium stores a computer program, wherein the computer program includes program instructions, and the program instructions are executed by the electronic device to enable the electronic device to execute the interface testing method according to any one of claims 1 to 7.

Images