Interface testing method and device and electronic equipment

Abstract

The invention discloses an interface testing method and device and electronic equipment. The method comprises the steps that in response to a request instruction, first target interface data of a target interface is obtained from interface metadata of a target service, and the interface metadata comprises all interface data of the target service; a target request corresponding to the first target interface data is generated, and the target request is used for indicating a target service to execute business logic corresponding to a target interface; sending the target request to the target service; and receiving an execution result of the target service, and determining a test result according to the execution result. According to the method and the device, the technical problem of low efficiency due to the fact that debugging and testing are carried out after codes, scripts and the like need to be manually modified for interface adaptation in related technologies when the service interface is changed is solved.

Description

Technical Field

[0001] This application relates to the field of network technology and security, and more specifically, to a method, apparatus, and electronic device for interface testing. Background Technology

[0002] In a rapidly iterating development environment, interfaces often need to be updated frequently. Manually modifying code and scripts to adapt the interfaces before debugging and testing is inefficient.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides a method, apparatus, and electronic device for interface testing, which at least solves the technical problem of low efficiency when service interfaces change, requiring manual modification of code, scripts, etc. to adapt the interface before debugging and testing.

[0005] According to one aspect of the embodiments of this application, an interface testing method is provided, comprising: in response to a request instruction, obtaining first target interface data of a target interface from interface metadata of a target service, wherein the interface metadata includes all interface data of the target service; generating a target request corresponding to the first target interface data, wherein the target request is used to instruct the target service to execute business logic corresponding to the target interface; sending the target request to the target service; receiving the execution result of the target service, and determining a test result based on the execution result.

[0006] In some embodiments of this application, in response to a request instruction, obtaining first target interface data of a target interface from the interface metadata of a target service includes: receiving a first selection instruction from a target object, wherein the first selection instruction includes a request method of the interface; filtering first interface data corresponding to the request method from the interface metadata of the target service; receiving a second selection instruction from the target object, wherein the second selection instruction is used to instruct the determination of first target interface data from the first interface data; obtaining parameter description information corresponding to the first target interface data, wherein the parameter description information is used to represent the parameter description corresponding to the first target interface data; receiving parameters input by the target object based on the parameter description information, and determining the first target interface data based on the parameters input by the target object.

[0007] In some embodiments of this application, the method further includes: traversing the interface metadata of the target service, generating multiple test cases corresponding to each interface of the interface metadata according to preset parameter rules, wherein the test cases are used to instruct the target service to execute the business logic of the corresponding interface under different execution conditions; sending the test cases to the target service for execution; and receiving the return results from the target service.

[0008] In some embodiments of this application, before sending the test cases to the target service for execution, the method further includes: obtaining a second interface that has a dependency relationship with the first interface corresponding to the first test case, wherein the dependency relationship includes pre-dependencies and post-dependencies, and the first test case is any one of the test cases; and determining the execution order of the second test cases corresponding to the second interface based on the dependency relationship.

[0009] In some embodiments of this application, multiple test cases are generated for each interface corresponding to the interface metadata according to preset parameter rules, including: obtaining a third interface from the interface metadata, wherein the third interface is any interface corresponding to the interface metadata; generating a third test case corresponding to the third interface, wherein the third test case includes test cases in which all parameters meet preset conditions, and the preset conditions do not include boundary values; generating a fourth test case corresponding to the third interface, wherein the fourth test case includes test cases in which at least one parameter is a boundary value; and generating a fifth test case corresponding to the third interface, wherein the fifth test case includes test cases in which at least one parameter does not meet the preset conditions.

[0010] In some embodiments of this application, after sending the target request to the target service, the method further includes: the target service obtaining the target interface in the target request; routing the target interface to the corresponding second target interface data in the configuration file, wherein the configuration file is used to store all interface metadata of the target service; executing the target request if the request parameters in the target request match the second target interface data; and generating an execution result corresponding to the target request.

[0011] In some embodiments of this application, if there is no second target interface data corresponding to the target interface in the configuration file and / or the request parameters in the target request do not match the second target interface data, the target service refuses to execute the target request and generates an error message.

[0012] In some embodiments of this application, before obtaining the first target interface data of the target interface from the interface metadata of the target service in response to a request instruction, the method further includes: obtaining the first interface metadata of the target service when a triggering condition is met; comparing the first interface metadata with the second interface metadata to obtain a comparison result, wherein the second interface metadata includes the historical interface metadata of the target service that has been stored; and updating the second interface metadata to the first interface metadata when the comparison result indicates a difference.

[0013] According to another aspect of the embodiments of this application, an interface testing apparatus is also provided, comprising: an acquisition module, configured to acquire first target interface data of a target interface from interface metadata of a target service in response to a request instruction, wherein the interface metadata includes all interface data of the target service; an execution module, configured to generate a target request corresponding to the first target interface data, wherein the target request is used to instruct the target service to execute business logic corresponding to the target interface; a sending module, configured to send the target request to the target service; and a determination module, configured to receive the execution result of the target service and determine the test result based on the execution result.

[0014] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory and a processor, wherein the memory is used to store program instructions; the processor is connected to the memory and is used to execute the method for implementing the above-described interface test.

[0015] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, the non-volatile storage medium including a stored computer program, wherein the device where the non-volatile storage medium is located executes the above-described interface testing method by running the computer program.

[0016] According to another aspect of the embodiments of this application, a computer program product is also provided, including computer instructions that, when executed by a processor, implement the above-described method for interface testing.

[0017] In this embodiment, a unified management approach for interface metadata is adopted. By obtaining data of the interface to be tested from the service, a request corresponding to the interface to be tested is generated for execution by the target service to obtain the test result. This achieves the goal that when the interface changes, only the interface metadata needs to be updated, and developers can focus on the business logic without having to manually implement cumbersome parameter verification. This reduces development costs and improves testing and debugging efficiency, thereby solving the technical problem that when the service interface changes, related technologies need to manually modify code, scripts, etc. to adapt the interface before debugging and testing, which is inefficient. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0019] Figure 1 This is a hardware structure block diagram of a computer terminal for an interface testing method according to an embodiment of this application;

[0020] Figure 2 This is a flowchart of an interface testing method according to an embodiment of this application;

[0021] Figure 3 This is a schematic diagram of the interaction flow of an interface testing method according to an embodiment of this application;

[0022] Figure 4 This is a schematic diagram of the system architecture of an interface testing method according to an embodiment of this application;

[0023] Figure 5 This is a schematic diagram of an interface testing apparatus according to an embodiment of this application. Detailed Implementation

[0024] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0025] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0026] To better understand the embodiments of this application, the technical terms involved in the embodiments of this application are explained below:

[0027] Command Line Interface (CLI): A way for users to interact with a computer or software system by entering command-line text. In a CLI environment, users enter specific commands at the command prompt to perform operations or obtain information, and the system provides corresponding feedback or performs operations based on the entered commands. CLI is commonly used in server environments, scripting, and automation tasks because it provides a fast and flexible way to interact, especially in environments without a graphical user interface.

[0028] In rapidly iterating development environments, interfaces are frequently updated, leading to repetitive development and maintenance of validation logic and test cases. Furthermore, server environments typically lack a UI and internal service ports are not publicly accessible, relying heavily on CLI for debugging and verification. This CLI also requires frequent adaptation to interface updates, resulting in the following problems: (1) High maintenance costs due to frequent interface changes. (2) Incomplete coverage and poor adaptability of manually written automated test cases. (3) Low development and testing efficiency, often requiring manual modification for adaptation before verification and debugging. (4) Difficult cross-team collaboration, as interface parameters and validation rules are difficult to standardize in cross-team development, increasing communication and integration costs.

[0029] To address the aforementioned technical problems, this application provides corresponding solutions, which are detailed below.

[0030] The interface testing method embodiments provided in this application can be executed on mobile terminals, computer terminals, or similar computing devices. Figure 1 A hardware block diagram of a computer terminal for implementing an interface testing method is shown. Figure 1 As shown, the computer terminal 10 may include one or more processors (shown as 102a, 102b, ..., 102n in the figure) (the processor may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission module 106 for communication functions connected via wired and / or wireless networks. In addition, it may also include: a display, a keyboard, a cursor control device, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, and a BUS bus. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0031] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be implemented wholly or partially as software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be wholly or partially integrated into any other element in the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as processor control (e.g., selection of a variable resistor termination path connected to an interface).

[0032] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the interface testing method in this embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the aforementioned interface testing method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0033] The transmission module 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission module 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission module 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0034] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10.

[0035] It should be noted here that, in some optional embodiments, the above... Figure 1 The computer terminal shown may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that... Figure 1 This is only one instance of a specific particular instance, and is intended to illustrate the types of components that may exist in the aforementioned computer terminal.

[0036] In the above operating environment, this application provides an embodiment of an interface testing method. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0037] Figure 2 This is a flowchart of an interface testing method according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:

[0038] Step S202: In response to the request instruction, obtain the first target interface data of the target interface from the interface metadata of the target service, wherein the interface metadata includes all interface data of the target service.

[0039] In step S202 above, the request instruction includes a command initiated by the CLI debugging tool or automated testing system to the server to obtain interface metadata or execute interface tests. The request instruction can start the data acquisition or testing process and is the trigger point of the entire testing and debugging mechanism.

[0040] The target service's interface metadata refers to a data collection that stores detailed information about all interfaces of the target service. This may include the interface's URL, request method, parameter fields, field types, value range, whether a field is required, default values, boundary values, etc.

[0041] The first target interface data refers to the interface information related to the target request instruction that is filtered out from the interface metadata of the target service. That is, the detailed rules of the interface (target interface) that needs to be tested or debugged, which are used to guide subsequent operations such as parameter generation, request construction and result verification.

[0042] When an automated testing system executes tests, the address of the target service and test requirements can be configured in advance. When the testing system receives the instruction to start testing, it can send a request to the target service through a predefined metadata retrieval interface (such as a REST API) to request the latest interface metadata. For example, the automated testing system can construct an HTTP GET request, carrying the unique identifier of the target service (such as a service ID or URL), and send it to the metadata provider interface of the server (i.e., the target service). After receiving the request, the server queries the interface metadata repository and returns the first target interface data that matches the request instruction. After receiving the metadata, the automated testing system parses it and generates corresponding test case data based on the first target interface data.

[0043] In CLI debugging tools, when developers or testers need to verify or debug specific interfaces, they can trigger the metadata retrieval process by entering specific commands via the CLI. The CLI tool has an internal processing module that can parse the user's commands and identify the target service and the interface information to be queried. For example, the CLI tool will construct an HTTP GET request, carrying the identifiers of the target service and interface, and send it to the server's metadata provider interface. The first target interface data returned by the server will be parsed by the CLI tool to generate command-line prompts and parameter input options, guiding the user to correctly fill in the parameters and construct a request that conforms to the interface specification. After the user completes the parameter input, the CLI tool will validate the parameters against the parsed first target interface data to ensure that the parameters conform to the interface definition, and then send the constructed request to the target service for debugging or verification.

[0044] To enable more precise selection and configuration of the testing environment, improve the relevance of testing, and facilitate rapid verification of interface functionality by developers and testers, the first target interface data can be determined through the following steps: receiving a first selection instruction from the target object, wherein the first selection instruction includes the interface request method; filtering the first interface data corresponding to the request method from the interface metadata of the target service; receiving a second selection instruction from the target object, wherein the second selection instruction is used to instruct the determination of the first target interface data from the first interface data; obtaining parameter description information corresponding to the first target interface data, wherein the parameter description information is used to represent the parameter description corresponding to the first target interface data; receiving the parameters input by the target object based on the parameter description information, and determining the first target interface data based on the parameters input by the target object.

[0045] The first selection instruction refers to a command issued by the user or system in a CLI debugging tool or automated testing system to specify the request method (such as GET, POST, PUT, DELETE) of a specific interface to be tested or debugged. It is the starting point of the process, helping the system to clarify the interface type that needs to be operated on. In some embodiments of this application, in a CLI debugging tool, when the user enters a command, the tool parses the input and identifies the selected request method (such as "--method GET"); in an automated testing system, the test plan or configuration file contains the request method to be used. Specifically, the CLI tool or automated testing system can parse the user input or configuration file using a parser to extract the request method information, which serves as the basis for subsequent metadata filtering.

[0046] The first interface data refers to the set of interface data corresponding to a specific request method, filtered from the interface metadata of the target service. The first interface data contains detailed information about all interfaces using that request method, such as URL, parameter fields, and field types, used to narrow down the metadata search scope and improve the efficiency of subsequent selection. In some embodiments of this application, after receiving request method information, the CLI tool or automated testing system sends a specific request to the target service, requesting the server to return the interface metadata for the specified request method. After receiving the request, the server can filter out relevant interface information based on the request method and return it to the client. After receiving the data, the client stores this information as the first interface data for further selection.

[0047] The second selection instruction refers to a further instruction issued by the user after receiving the first selection instruction and obtaining the first interface data. This instruction is used to select a specific interface to be tested or debugged from the first interface data. The second selection instruction helps determine the specific target for testing or debugging, i.e., the first target interface data. In some embodiments of this application, in the CLI tool, the user further inputs a specific command based on the first selection instruction to select the interface to be debugged or tested (e.g., "--interface / api / v1 / users"). In the automated testing system, the test plan lists the specific interfaces to be tested. The client parses this instruction to extract the unique identifier of the interface, which is used to accurately locate the detailed information of the specific interface from the first interface data.

[0048] Parameter description information refers to detailed descriptions of interface parameters in the first target interface data, including parameter name, type, function, whether it is required, default value, and allowed value range. Parameter description information serves as the rule that users or automated testing systems must follow when generating test requests to ensure that the requests conform to the interface specification. In some embodiments of this application, the first target interface data can be further filtered from the first interface data based on the interface information extracted from the second selection instruction. By parsing the first target interface data, parameter description information, including parameter name, type, and required status, can be extracted. In CLI tools, this information will be used to generate parameter input prompts; in automated testing systems, it will be used to generate test cases.

[0049] The first target interface data refers to the detailed rules and descriptions of a specific interface selected from the first interface data based on the user's second selection instruction. It serves as the basis for subsequent parameter generation, request construction, and result verification, and includes all necessary information about the interface, such as URL, parameter fields, field types, value ranges, whether they are required, default values, and boundary values. In some embodiments of this application, in a CLI tool, the user can fill in parameters according to the parameter description information. The tool will verify whether the user input conforms to the parameter rules and then construct the request. In an automated testing system, the system will automatically generate a parameter set based on the parameter rules, including normal values, boundary values, and abnormal values, and then construct a test request. Specifically, the CLI tool or automated testing system can ensure the correctness and compliance of the parameters through parameter generation and verification modules. Finally, these parameters are combined with the interface request structure described in the first target interface data to form complete first target interface data, which serves as the basis for subsequent request sending.

[0050] To enable timely detection and handling of interface changes, the following steps can be performed: when the triggering conditions are met, obtain the first interface metadata of the target service; compare the first interface metadata with the second interface metadata to obtain the comparison result, wherein the second interface metadata includes the historical interface metadata of the target service that has already been stored; if the comparison result indicates that there is a difference, update the second interface metadata to the first interface metadata.

[0051] Triggering conditions can be responses to various situations. For example, it can be a periodic check, which automatically checks whether the target service's interface metadata has been updated by setting a time period, such as hourly or daily; it can also be an event listener, which listens for server-side events (such as version update events) and immediately responds and obtains the latest first interface metadata once the server-side interface changes; or it can be manually triggered, which means that users can manually trigger update checks, such as executing update commands before starting CLI tools or starting automated tests.

[0052] After obtaining the first interface metadata, the CLI or automated testing system will compare it with the second interface metadata stored locally to check for any differences. For example, the comparison process can be based on the version number, timestamp in the metadata, or by directly comparing the content of the metadata, such as whether the interface URL, request method, parameter fields, etc., have changed.

[0053] If the comparison results show discrepancies, it indicates that the target service's interface has changed. In this case, the CLI or automated testing system will replace the existing second interface metadata with the latest acquired first interface metadata. The update can be performed automatically or after manual confirmation, depending on security and system design.

[0054] Step S204: Generate a target request corresponding to the first target interface data, wherein the target request is used to instruct the target service to execute the business logic corresponding to the target interface.

[0055] In step S204 above, the target request refers to a network request constructed based on the first target interface data, used to trigger the target service to execute specific business logic, transforming the testing or debugging requirements into instructions that the server can understand and execute. The target request satisfies the protocols and specifications defined in the first target interface data, including the request URL, method (such as GET, POST, etc.), parameter format, and value. In some embodiments of this application, in the CLI debugging tool, the user manually inputs parameters according to the provided parameter description information. The CLI tool verifies whether the parameters conform to the definitions in the first target interface data and encapsulates these parameters into a request format conforming to protocols such as HTTP or gRPC, forming a target request. For example, if a POST request is defined in the first target interface data, the CLI tool ensures that the parameters are organized according to the structure of the request body, and adds necessary header information, such as Content-Type, so that the server can correctly parse and process the request.

[0056] Business logic refers to the functional processing flow designed and implemented on the server side to respond to specific interface requests. It encompasses data processing, application of business rules, and possible invocation of external resources or services. Business logic is the core of the server, determining how the service responds to client requests and what format of data or status code is returned. In some embodiments of this application, after the target request is constructed, it is sent to the target service via the network. Upon receiving the target request, the server (i.e., the target service) parses the information in the request to determine the business logic to be executed. In some embodiments of this application, the target service can also read the first target interface data for parameter validation to ensure that the request conforms to the interface specification. If the parameter validation passes, the server will execute the corresponding business processing, including data operations and application of business rules, and finally generate response data, which is returned to the client. The response data may contain the results of the business processing, status codes, or error information. Based on this information, the client can evaluate the correctness and performance of the interface.

[0057] Through the above steps, CLI debugging tools and automated testing systems can generate and send target requests that conform to the server interface specifications, trigger the server to execute specific business logic, thereby verifying the functionality and performance of the interface and improving the accuracy and efficiency of testing and debugging.

[0058] Step S206: Send the target request to the target service.

[0059] In step S206 above, the target service refers to a backend system or microservice that provides specific business logic and functions. It receives target requests from clients, parses the request data, performs corresponding business processing, and returns the corresponding response results.

[0060] After constructing the target request, the CLI debugging tool or automated testing system sends the target request to the target service over the network. In some embodiments of this application, for interfaces based on the HTTP / HTTPS protocol, the CLI tool or automated testing system can use an HTTP client library (such as requests, HttpClient) to construct an HTTP request object based on the request URL, method, header information, and request body, and then send the request through methods of the client library (such as send, execute). For interfaces using the gRPC protocol, a gRPC client library (such as grpcio, grpc-java) can be used to construct a gRPC request object based on the Remote Procedure Call (RPC) methods defined in the interface metadata, and then call the corresponding RPC method to send the request. gRPC requests can process requests and responses through serialization and deserialization of data, using protobuf as the data transmission format to improve efficiency and compatibility.

[0061] After receiving the target request, the target service parses the request, executes business logic processing, and returns a response. In some embodiments of this application, for HTTP responses, the tool parses the HTTP status code to determine whether the request was successful. If the request is successful, it further parses the data in the response body, such as in JSON or XML format, to extract the execution result of the business logic. For failed requests, the tool locates the cause of the problem based on the status code and error information in the response body; for gRPC responses, the tool deserializes the response data and extracts the processing result based on the data structure returned by the server. gRPC responses typically contain detailed error information, which is used to diagnose and fix problems if the request fails.

[0062] To ensure that the target service can correctly parse and execute the test request, the following steps can also be performed: the target service obtains the target interface in the target request; the target interface is routed to the corresponding second target interface data in the configuration file, where the configuration file is used to store all interface metadata of the target service; if the request parameters in the target request match the second target interface data, the target request is executed; and the execution result corresponding to the target request is generated.

[0063] A target interface refers to a specific interface specified in a target request, which is typically uniquely identified in the request by information such as the URL and request method (e.g., GET, POST). In some embodiments of this application, when the target service receives the target request, it can parse the URL and request method contained in the request to determine the target interface corresponding to the target request.

[0064] In the target service, the configuration file stores all interface metadata. The configuration file can be a JSON file, an XML file, a database table, or a dedicated configuration management system. The second target interface data refers to the interface metadata extracted from the configuration file that matches the target interface in the target request. After receiving the request, the server looks up the corresponding interface rule in the configuration file, i.e., the second target interface data, based on the interface identifier (such as URL and method) in the request. This second target interface data is used for subsequent parameter validation and request processing. In some embodiments of this application, after determining the target interface, the server looks up the corresponding second target interface data in the configuration file based on the target interface information. For example, it might use the URL and request method as keys to query the corresponding rule information from the configuration file, including hash table lookups, database queries, or API calls.

[0065] After locating the second target interface data, the server validates the request parameters in the target request to ensure they conform to the rules defined in the interface metadata. If the parameter validation passes—meaning the parameter format, type, and value range match the second target interface data—the server forwards the request to the corresponding business logic processing module to execute the actual business processing. For example, the server uses the parameter validation module to verify each request parameter against the field rules defined in the interface metadata. Only after all parameters pass validation will the server call the business logic processing module to execute the request.

[0066] The business logic processing module executes corresponding business operations based on the parameters in the request, and generates execution results upon completion, such as database query results, file operation results, calculation results, etc. The generated execution results are encapsulated into response data. The response data can be a JSON object, an XML document, a status code, or other predefined data structures, used to provide feedback on the processing results.

[0067] In scenarios where interfaces change frequently and require rapid feedback, error messages can help testers quickly locate interface problems. Specifically, if the configuration file does not contain second target interface data corresponding to the target interface and / or the request parameters in the target request do not match the second target interface data, the target service will refuse to execute the target request and generate an error message.

[0068] When the server parses a target request and attempts to find the corresponding interface information in the configuration file that matches the URL and method in the request, if no matching second target interface data is found, it indicates that the interface is not registered on the server or the parameters are configured incorrectly. In this case, the server can generate an error response (i.e., an error message), such as an HTTP 404 status code, indicating that the corresponding interface was not found. Alternatively, the response body can include a more detailed error message explaining the specific problem, such as "interface not found in configuration." Specifically, the server uses a pre-defined query mechanism (such as hash table lookup or database query) to search for the corresponding interface's metadata in the configuration file based on the request's URL and method. If the query result is empty, meaning the interface is not defined in the configuration file, the server will generate an error response.

[0069] When the server finds the data for the second target interface corresponding to the target interface and begins validating the request parameters, if it finds that the type, format, or value range of the request parameters does not conform to the rules defined in the configuration file, the server will refuse to execute the target request and generate an error message, such as an HTTP 400 status code, indicating that the request parameters are incorrect. Specifically, the server can use modules to verify whether the request parameters conform to the rules defined in the interface metadata. Validation can include type checking, format validation, value range checking, and mandatory field detection to ensure that the parameters are consistent with the interface specification.

[0070] Through the above steps, the server can ensure that it can promptly generate and return error messages when interface metadata is missing or request parameters are not standardized, thus preventing invalid or erroneous requests from being executed and ensuring the stability and security of the service.

[0071] Step S208: Receive the execution result of the target service and determine the test result based on the execution result.

[0072] In step S208 above, the execution result refers to the response data returned to the client by the target service after receiving and processing the target request. The execution result may include the processing result of business logic, status codes, error messages, or other feedback data, used to inform the client of the processing result of the request. In some embodiments of this application, after sending the target request, the CLI debugging tool or automated testing system waits to receive a response from the target service. The response may be an HTTP response, a gRPC response, or a response from another network protocol, containing the execution result of the server processing the request.

[0073] Test results refer to a comprehensive evaluation of the execution status of test requests or test cases and the verification results of interface functions based on the execution results of the target service. This evaluation determines whether the test passed and whether the interface has functional defects or performance issues. In some embodiments of this application, after receiving and parsing the execution results of the target service, the actual result of request processing can be evaluated based on preset test rules or expected results to determine whether it meets expectations. The test results may include states such as pass, failure, and exception, as well as a detailed test report to demonstrate the specific circumstances and results of the test.

[0074] In some embodiments of this application, JQ expressions can be written to validate the actual response body returned by the server based on the response structure defined in the interface metadata. Specifically, a validation function can be defined that accepts the server response and the JQ expression in the interface metadata as parameters. Inside the validation function, the JQ library is used to parse the response body and execute the defined expressions. If all expressions pass validation, the test passes; if any expression fails validation, the test fails, and specific validation failure information, such as "incorrect type of the .user.id field," is recorded. Alternatively, JQ expressions can be used to verify whether the data returned by the server conforms to the expected business logic, based on the business logic validation rules defined in the interface metadata. Specifically, for a calculation interface, the test system dynamically generates JQ expressions, matches them with the validation rules defined in the interface metadata, and then executes these expressions to verify whether the values ​​of the result fields are correct. If the validation passes, it indicates that the business logic is executed correctly; if the validation fails, the test system records detailed validation failure information, such as "the calculation result does not match the expectation," and adds it to the test report. For example, if the interface is supposed to return a calculation result, the metadata might contain a JQ expression such as (result = (num1 * num2) + num3) to check if the value of the result field is equal to the product of num1 and num2 plus num3.

[0075] By automatically traversing and generating test cases, interface testing can be automated and comprehensive. Specifically, it traverses the interface metadata of the target service, generates multiple test cases for each interface of the interface metadata according to preset parameter rules, and the test cases are used to instruct the target service to execute the business logic of the corresponding interface under different execution conditions; sends the test cases to the target service for execution; and receives the return results from the target service.

[0076] In automated testing, a test case is a set of predefined test conditions and expected results used to verify whether the target service behaves as expected under specific inputs. Test cases cover various execution conditions of the interface, including normal conditions, boundary conditions, and abnormal conditions, ensuring the comprehensiveness and depth of the testing.

[0077] In some embodiments of this application, the automated testing system reads interface metadata and then automatically generates test data according to preset strategies and rules, including parameter type checking, value range coverage, boundary value testing, and abnormal input testing.

[0078] By generating multiple test cases covering normal, boundary, and outlier values ​​of parameters, the robustness and fault tolerance of the interface can be comprehensively tested. Specifically, it can be done as follows: Obtain a third interface from the interface metadata, where the third interface is any interface corresponding to the interface metadata; generate a third test case corresponding to the third interface, where the third test case includes test cases where all parameters meet preset conditions, excluding boundary values; generate a fourth test case corresponding to the third interface, where the fourth test case includes test cases where at least one parameter is a boundary value; and generate a fifth test case corresponding to the third interface, where the fifth test case includes test cases where at least one parameter does not meet the preset conditions.

[0079] The third test case refers to a test case generated for the third interface where all parameters meet preset normal conditions, but do not include boundary values. This test case is used to verify the functional correctness of the interface within the normal parameter range. In some embodiments of this application, a set of test cases with all parameters within the normal range can be generated based on the parameter fields and normal value ranges defined in the interface metadata. For example, one or more random values ​​within the defined value range can be generated for each parameter field, but excluding boundary values.

[0080] The fourth test case refers to a test case generated against the third interface that contains at least one parameter as a boundary value. Boundary value testing is used to verify the behavior of the interface under the boundary conditions of the parameter, ensuring that the interface can correctly handle these special cases. In some embodiments of this application, at least one boundary value test case is generated for each parameter based on the parameter metadata of the third interface. For example, for a numeric parameter, a minimum value and a maximum value test case are generated.

[0081] The fifth test case refers to a test case generated against the third interface that contains at least one parameter that does not meet the preset normal conditions. This test case is used to verify the fault tolerance and exception handling mechanism of the interface, ensuring that the interface can handle illegal parameter input. In some embodiments of this application, at least one abnormal value that does not meet the preset conditions can be generated for each parameter, such as a value outside the value range, an illegal data type (such as setting a numeric parameter as a string), etc.

[0082] In addition to the three types of test cases mentioned above, other test cases can be generated, such as empty parameter / missing parameter test cases, which are used to check the response of the interface when the parameter is missing or empty, helping to verify the interface's dependency on required parameters and its handling mechanism for empty parameters; and type change test cases, which are used to verify the interface's tolerance for parameter types, so that even if the parameter input type is inconsistent with the type defined in the metadata, the interface should be able to recognize and return meaningful error information.

[0083] In some embodiments of this application, HTTP requests can be constructed based on generated test cases and then sent to the target service. The automated testing system needs to convert test cases into actual request data, such as converting the parameters described in the test cases into specific data formats like JSON or XML. After the test cases are digitized, a network request library can be used to construct requests based on the request methods (GET, POST, etc.) specified in the interface metadata and send them to the target service. After sending the request, the automated testing system listens for the target service's response, receives the returned results, and then processes and verifies them. For example, using the response receiving mechanism of the network request library, the HTTP response data returned by the target service can be captured. To avoid congestion, the response data can be received asynchronously, and the received response data can be parsed to extract key data such as the execution results of the business logic, status codes, and error messages, preparing for subsequent test result evaluation.

[0084] To avoid inaccurate test results due to untested or failed dependent interfaces, the following steps can be performed before sending test cases to the target service for execution: Obtain the second interface that has a dependency relationship with the first interface corresponding to the first test case, wherein the dependency relationship includes pre-dependencies and post-dependencies, and the first test case is any one of the test cases; determine the execution order of the second test cases corresponding to the second interface based on the dependency relationship.

[0085] A pre-dependency means that the correct execution of one interface (the first interface) depends on the output of another interface (the second interface); a post-dependency means that the output of one interface (the first interface) may be depended on by another interface (the second interface).

[0086] In some embodiments of this application, a second interface that has a dependency relationship with a first interface can be identified by reading interface metadata. The dependency relationship can be explicitly marked in the metadata as a field (such as "dependent interface"), or dynamically determined through interface logic analysis. For example, in the interface metadata, each interface can explicitly specify the URLs or names (annotation information) of its pre-dependent and post-dependent interfaces. When the automated testing system reads the metadata, it can determine the second interface based on the annotation information. Alternatively, the dependency relationship between interfaces can be dynamically identified by parsing the interface logic code. Specifically, if the first interface contains code that calls the second interface in its logic, the system can determine that the second interface is a pre-dependent of the first interface.

[0087] To ensure the accuracy of test results, automated testing systems need to adjust the execution order of test cases based on interface dependencies. For example, if the second interface is a prerequisite dependency of the first interface, then the second test case should be executed before the first test case; if the second interface is a subsequent dependency of the first interface, then the second test case should be executed after the first test case. In some embodiments of this application, the execution order of test cases can be adjusted by checking the dependency annotations related to the first interface in the interface metadata, ensuring that prerequisite dependency test cases are executed before the first test case, and subsequent dependency test cases are executed after them; alternatively, an interface dependency graph can be constructed, where nodes represent interfaces and edges represent dependencies. The system will use depth-first search (DFS) or breadth-first search (BFS) algorithms to traverse the dependency graph and determine the execution order of test cases based on topological sorting, ensuring that all dependencies are handled correctly.

[0088] Through the above steps, the automated testing system can effectively identify and handle the dependencies between interfaces, ensuring that the execution order of test cases conforms to the interface logic, thereby avoiding inaccurate test results due to untested or failed dependent interfaces.

[0089] Through steps S202 to S208 above, a unified management approach for interface metadata is adopted. By obtaining data of the interface to be tested from the service, a request corresponding to the interface to be tested is generated for execution by the target service to obtain the test results. This achieves the goal of only needing to update the interface metadata when the interface changes, allowing developers to focus on business logic without having to manually implement cumbersome parameter verification. This reduces development costs and improves testing and debugging efficiency, thereby solving the technical problem of low efficiency caused by the need to manually modify code and scripts to adapt the interface before debugging and testing when the service interface changes.

[0090] Figure 3This is a schematic diagram of the interaction flow of an interface testing method according to an embodiment of this application, such as... Figure 3 As shown, in some embodiments, interface testing can be performed through the following steps:

[0091] (1) When the target object updates the interface, it should update and maintain the unified interface metadata: Whenever the interface logic on the server side changes, the architect or developer needs to update the interface metadata file to ensure that the information in the file matches the latest interface logic. Interface metadata can support multiple protocols. Taking the HTTP protocol interface as an example, it mainly includes the interface URL, request method, request parameter rules, test rules, etc. A URL is classified as an interface, and an interface can contain multiple request methods, corresponding to multiple interfaces. The above content is arranged and defined in an xlsx format file, called the interface definition table. Each version of the service corresponds to one file.

[0092] For example, development teams can use version control systems (such as Git) to manage interface metadata, ensuring that every update is recorded for easy backtracking and version management; they can also use automated metadata update tools to automatically update interface metadata based on code changes, reducing errors and workload from manual operations.

[0093] (2) Developing the Interface Logic for the Target Object: Developing the interface logic refers to implementing specific business functions and data processing logic in the server-side module, without directly focusing on parameter format and value range validation, as this part of the work will be automatically completed by the underlying library based on the interface metadata. Developers write the business logic code for the interface using programming languages ​​(such as Java, Go, Python, etc.) according to the requirements document and interface design specifications. This code mainly handles business data, calls other services, or performs database operations.

[0094] For example, developers use appropriate programming languages ​​and frameworks to implement interface logic in server-side modules, including but not limited to data processing, application of business rules, and state management. While writing the interface logic, developers also need to write unit test code to ensure the correctness and stability of the business logic.

[0095] (3) Read interface metadata when the server starts: When the server starts, it needs to read the latest interface metadata file from the storage location and load it into memory so that parameter verification and interface matching can be performed when receiving requests.

[0096] For example, during the initialization phase of a server-side program, it reads an interface metadata file from a predefined location. This metadata could be a local file, a database record, or a resource on a remote server. The read metadata is then converted into a data structure that is easy for the program to manipulate, such as a JSON object, and loaded into memory for subsequent request processing.

[0097] (4) The target object calls the initialization interface through the CLI debugging module: The target object, namely the developer, operation and maintenance personnel or tester, uses the CLI debugging tool to connect to the server and calls the initialization interface to obtain the latest interface metadata.

[0098] For example, the target object enters a specific initialization command in the CLI tool, which contains the server address and authentication information (such as API key). After receiving the command, the CLI tool will send a specific HTTP request (such as a GET request) to the server to request the interface metadata.

[0099] (5) CLI debugging module reads interface metadata from the server: The CLI tool obtains interface metadata from the server by initializing the interface and parses it in order to display it to the user and generate subsequent debugging requests.

[0100] For example, CLI tools parse the API metadata response returned from the server and convert it into a CLI-readable format, such as a list or table. To improve debugging efficiency, CLI tools can cache API metadata locally, avoiding the need to retrieve the metadata before each debugging session.

[0101] (6) CLI debugging module returns interface description and parameter description to the target object: The CLI tool converts the read interface metadata into user-friendly descriptions, including the functional description of each interface, the meaning, type, and whether the parameter fields are required or not.

[0102] For example, CLI tools display interface and parameter descriptions in text or formatted output in the command-line interface for users to view. In addition, they can provide interactive prompts to guide users in entering the correct parameter values.

[0103] (7) After the target object fills in the parameters, it calls the CLI debugging module: Based on the parameter description provided by the CLI tool, the target object fills in the specific test parameters and calls the CLI tool again to send the debugging request.

[0104] For example, the target object enters the corresponding parameter values ​​for the interface to be debugged according to the prompts of the CLI tool. These values ​​can be entered manually or read from a file. After receiving the parameters, the CLI tool packages them into a request that meets the interface metadata requirements and sends it to the server for debugging.

[0105] (8) After receiving the parameters, the CLI generates a target request and interacts with the server: The CLI tool constructs a request that conforms to the protocol specification based on the parameters input by the user and the interface metadata, and sends it to the server for processing.

[0106] For example, CLI tools can construct requests using user-provided parameters according to the specifications of HTTP, gRPC, or other protocols. For instance, if the interface metadata requires the use of the POST method, a POST request can be sent over the network to the specified URL on the server, triggering the execution of the interface logic.

[0107] (9) The CLI debugging module sends the debugging results to the target object: After the server processes the request, it returns the response results to the CLI tool. The CLI tool parses the response and displays the results in a user-friendly format.

[0108] For example, CLI tools can parse the response data returned by the server, convert it into text or formatted output for easy reading and understanding by users, and can also display debugging results in the command-line interface, which may include response status, data, error messages, etc.

[0109] (10) Target object triggers automated testing module: The target object, usually the tester, can trigger the automated testing module through command line or other means to start automated testing of the server interface.

[0110] For example, testers can enter specific test commands in the CLI tool or select test tasks in the graphical interface of the automated test system. After receiving the trigger signal, the automated test module will start scheduling test tasks and executing predefined test processes.

[0111] (11) The automated testing module reads the interface metadata of the server: Before executing the test, the automated testing module needs to obtain the latest interface metadata in order to generate test cases that match the current interface version.

[0112] For example, the automated testing module can automatically call the server's initialization interface to obtain the latest interface metadata. The testing module then parses the interface metadata and extracts the parameter information required to generate test cases.

[0113] (12) The automated testing module generates test cases and sends them to the server for execution: The automated testing module generates test cases covering various test scenarios based on the interface metadata, including normal value, boundary value, and abnormal value tests, and automatically executes the test cases and sends requests to the server.

[0114] For example, the automated testing module can generate various test cases based on the parameter rules in the interface metadata, including but not limited to normal value testing, boundary value testing, and outlier value testing. The generated test cases can be executed in batches and sent to the server via CLI tools or directly over the network to observe the server's response.

[0115] (13) The automated testing module generates a test report based on the execution results and returns it to the target object: After the automated testing module executes all test cases, it can generate a detailed test report, including test results, pass rate, error information, etc., and send the report to the testers.

[0116] For example, the automated testing module can collect the execution results of all test cases, including success, failure, and exception statuses. Based on the summarized results, the testing module generates a test report, which can be in HTML, PDF, or JSON format for easy reading and subsequent analysis. The test report can be displayed by testers via email, FTP, or directly on the automated testing system's interface.

[0117] Figure 4 This is a system architecture diagram of an interface testing method according to an embodiment of this application, such as... Figure 4 As shown, the interface testing system involves collaboration among architects, developers, operations personnel, and testers. Through interaction between the server and interface metadata, CLI debugging tools, and automated testing, it enables interface testing and maintenance. Specifically:

[0118] (1) Interface Metadata. Interface metadata includes detailed information such as the interface's URL, request method, parameter fields, field types, value range, whether they are required, default values, and boundary values. Interface metadata contains interface-related information and is maintained uniformly by the architect or developers, providing a reference when interfacing with external modules / teams. This metadata file is the foundation of the entire system, centrally managed, and updated as the interface changes.

[0119] (2) Server-side. The interface logic is maintained by the developers. The interface metadata is read at startup and can be used by CLI debugging tools and automated testing systems. When the server starts, it reads the interface metadata through the application's underlying library. When the underlying library receives an interface request, it performs parameter format validation, boundary value judgment, etc., based on the corresponding interface metadata. If the interface is valid, the business logic written by the developers will continue to be executed.

[0120] In some embodiments of this application, the server obtains the interface definition table during compilation and converts it into a JSON configuration file using a conversion tool. This tool validates the content in the table during the conversion process; if errors are found, compilation fails. After successful compilation, this file and the server program can be packaged together and deployed to the production environment. The server reads this file upon startup. When the server receives a request, it determines the unique interface based on the URL and request method, and then routes the request to the corresponding interface metadata. If routing fails, exception handling is initiated, and the request is rejected. If routing succeeds, the request method and parameters are validated. If validation passes, the processing logic written by the developers is executed; if validation fails, exception handling is again initiated, and an error message is returned.

[0121] (3) CLI debugging tool. The CLI debugging tool automatically reads interface data from the server upon startup, allowing developers, operations personnel, and testers to quickly and conveniently access the interface. It is mainly used for functional debugging, process testing, and fault location. In the CLI (Command Line Interface) tool, the interface metadata of the target service is obtained on the first run, and the corresponding options and command line instructions are generated to facilitate developers and testers to quickly verify the interface functions.

[0122] In some embodiments of this application, to ensure operational security, a CLI tool is used. First, a CLI login command must be executed, specifying the server to be accessed. After successful login, the CLI tool automatically obtains interface metadata from the server through a specific interface. It first prompts the user to select a request method. After the user selects a method, the CLI extracts the names and descriptions of all interfaces supporting that method and provides this information. When the user selects an interface, it extracts the interface's parameter information, including but not limited to parameter descriptions, whether fields are required, value ranges, and formats, and provides this information to the user. After the user enters the parameters according to the prompts, the CLI encapsulates the parameters according to the metadata requirements and sends them to the server. The results are then presented to the user upon return.

[0123] (4) Automated Testing System. During execution, the automated testing system reads interface data from the server, automatically generates test case data, and executes it, allowing testers to review test reports to verify product quality. In the automated testing system, the interface metadata information of the target service is first obtained during test execution, and various types of test case data are generated to ensure complete coverage and stability of the interface.

[0124] In some embodiments of this application, when the automated testing system is executed, it reads the service address of the configured device under test, obtains the interface metadata from the device under test through a specific interface, traverses all interfaces, generates random normal values, boundary values, random abnormal values, special character values, etc. according to parameter rules, and determines whether the interface has pre- or post-interface dependencies before execution. If so, they are executed sequentially. After execution, the returned results are verified according to the verification rules in the metadata (using jq expression syntax), and the results are recorded in the test report for review by testers.

[0125] This application reduces the workload of manually writing and maintaining test cases and debugging scripts by driving automated verification, test generation, and CLI tool adaptation through interface metadata, thereby lowering maintenance costs and improving development and testing efficiency. Furthermore, the self-adaptive testing mechanism simplifies configuration in the CI / CD process, increases deployment frequency and code delivery efficiency, and facilitates the rapid release of stable versions to meet the needs of agile development. In addition, supporting customer self-service debugging and testing through CLI tools makes API products easier to use, improves customer development experience and satisfaction, and provides additional value to platform-based API services. Finally, the unified interface metadata format promotes the standardization of interface design and testing, making interface design, verification, and debugging more standardized, helping enterprises achieve higher levels of technical management, improving the long-term maintainability of code repositories and interface systems, and enhancing team collaboration efficiency, thus contributing to more efficient product iteration and release.

[0126] Figure 5 This is a structural diagram of an interface testing apparatus according to an embodiment of this application, such as... Figure 5 As shown, the device includes:

[0127] The acquisition module 502 is used to obtain the first target interface data of the target interface from the interface metadata of the target service in response to the request instruction, wherein the interface metadata includes all interface data of the target service;

[0128] The execution module 504 is used to generate a target request corresponding to the first target interface data, wherein the target request is used to instruct the target service to execute the business logic corresponding to the target interface;

[0129] Sending module 506 is used to send the target request to the target service;

[0130] The determination module 508 is used to receive the execution result of the target service and determine the test result based on the execution result.

[0131] It should be noted that, Figure 5 The apparatus shown is used to perform interface testing. Figure 2 The interface testing method shown is therefore Figure 2 The explanations and instructions regarding the interface testing methods in [the document] also apply to [other applications]. Figure 5 The apparatus for interface testing shown will not be described in detail here.

[0132] This application also provides an electronic device, which includes a memory and a processor, wherein the memory is used to store program instructions; the processor is connected to the memory and is used to execute the steps of implementing the interface testing method in various embodiments of this application.

[0133] For example, a processor performs the following functions by executing program instructions stored in memory:

[0134] In response to the request instruction, the system retrieves the first target interface data of the target interface from the interface metadata of the target service, wherein the interface metadata includes all interface data of the target service; generates a target request corresponding to the first target interface data, wherein the target request is used to instruct the target service to execute the business logic corresponding to the target interface; sends the target request to the target service; receives the execution result of the target service, and determines the test result based on the execution result.

[0135] This application also provides a non-volatile storage medium including a stored computer program, wherein the device containing the non-volatile storage medium executes the steps of the interface testing method in various embodiments of this application by running the computer program.

[0136] This application also provides a computer program product, including computer instructions that, when executed by a processor, implement the steps of the interface testing method in various embodiments of this application.

[0137] This application also provides a computer program that, when executed by a processor, implements the steps of the interface testing method in various embodiments of this application.

[0138] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0139] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0140] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0141] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0142] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0143] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0144] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for interface testing, characterized in that: include: In response to the request instruction, acquiring first target interface data of the target interface from interface metadata of the target service, wherein the interface metadata includes all interface data of the target service; Generate a target request corresponding to the first target interface data, wherein the target request is used to instruct the target service to execute the business logic corresponding to the target interface; sending the target request to the target service; An execution result of the target service is received, and a test result is determined according to the execution result.

2. The method according to claim 1, characterized in that In response to the request instruction, obtaining first target interface data of the target interface from the interface metadata of the target service includes: Receiving a first selection instruction of a target object, wherein the first selection instruction includes a request method of an interface; Filtering first interface data corresponding to the request method from the interface metadata of the target service; receiving a second selection instruction of the target object, wherein the second selection instruction is used to instruct to determine the first target interface data from the first interface data; Acquire parameter description information corresponding to the first target interface data, wherein the parameter description information is used to represent a parameter description corresponding to the first target interface data; Parameters input by the target object according to the parameter description information are received, and the first target interface data is determined according to the parameters input by the target object.

3. The method according to claim 1, characterized in that The method further comprises: Traversing the interface metadata of the target service, generating a plurality of test cases corresponding to each interface of the interface metadata according to a preset parameter rule, wherein the test case is used to instruct the target service to execute the business logic of the corresponding interface under different execution conditions; Sending the test case to the target service for execution; Receive a return result from the target service.

4. The method according to claim 3, characterized in that Before sending the test case to the target service for execution, the method further includes: Acquire a second interface having a dependency relationship with a first interface corresponding to a first test case, wherein the dependency relationship includes a pre-dependency and a post-dependency, and the first test case is any one of the test cases; An execution order of second test cases corresponding to the second interface is determined according to the dependency relationship.

5. The method according to claim 3, characterized in that: Generate multiple test cases corresponding to each interface of the interface metadata according to preset parameter rules, including: Acquire a third interface from the interface metadata, wherein the third interface is any one interface corresponding to the interface metadata; Generate a third test case corresponding to the third interface, wherein the third test case includes a test case in which all parameters meet preset conditions, and the preset conditions do not include boundary values; Generate a fourth test case corresponding to the third interface, wherein the fourth test case includes at least one test case whose parameter is the boundary value; A fifth test case corresponding to the third interface is generated, wherein the fifth test case includes a test case in which at least one parameter does not satisfy the preset condition.

6. The method according to claim 1, characterized in that After sending the target request to the target service, the method further includes: The target service obtains the target interface in the target request; Routing the target interface to corresponding second target interface data in a configuration file, wherein the configuration file is used to store all interface metadata of the target service; In case the request parameter in the target request matches the second target interface data, executing the target request; Generate an execution result corresponding to the target request.

7. The method according to claim 6, characterized in that When the second target interface data corresponding to the target interface does not exist in the configuration file and / or the request parameters in the target request do not match the second target interface data, the target service refuses to execute the target request and generates an error prompt message.

8. The method according to claim 1, characterized in that Before obtaining first target interface data of the target interface from the interface metadata of the target service in response to the request instruction, the method further includes: When a trigger condition is met, obtaining first interface metadata of the target service; Comparing the first interface metadata with the second interface metadata to obtain a comparison result, wherein the second interface metadata includes the stored historical interface metadata of the target service; When the comparison result indicates that there is a difference, the second interface metadata is updated to the first interface metadata.

9. An interface testing device, characterized in that: include: An acquisition module, configured to acquire first target interface data of a target interface from interface metadata of a target service in response to a request instruction, wherein the interface metadata includes all interface data of the target service; An execution module, configured to generate a target request corresponding to the first target interface data, wherein the target request is used to instruct the target service to execute the business logic corresponding to the target interface; A sending module, used for sending the target request to the target service; The determination module is used to receive the execution result of the target service and determine the test result according to the execution result.

10. An electronic device, characterized in that: include: A memory and a processor, wherein the memory is used to store program instructions; the processor is connected to the memory and is used to execute the method for implementing the interface test described in any one of claims 1 to 8.

11. A non-volatile storage medium, characterized in that: The non-volatile storage medium includes a stored computer program, wherein the device where the non-volatile storage medium is located executes the interface testing method described in any one of claims 1 to 8 by running the computer program.

12. A computer program product comprising computer instructions, characterized in that: When the computer instructions are executed by a processor, the interface testing method described in any one of claims 1 to 8 is implemented.

Images