Interface testing method and device, equipment, storage medium and program product

Abstract

The invention discloses an interface testing method and device, equipment, a storage medium and a program product, in the interface testing process, under the condition that a uniform resource location address URL of an interface document input by a user in an interface interface is received, an interface document generated based on the URL is obtained, and the interface document is generated based on the URL. Respectively matching the request addresses of all the interfaces in the system with the request addresses of the interfaces stored in the interface library to obtain a matching result; updating the interface in the interface list and the use case corresponding to the interface based on the matching result, and labeling the interface and the use case corresponding to the interface; displaying the interface of the interface list and the information of the use case corresponding to the interface on the target interface; according to the method, the interface document can be analyzed in real time, the interface state can be automatically updated and marked, meanwhile, the test case is dynamically updated, the generation efficiency of the test case can be improved, and the maintenance cost is reduced.

Description

Technical Field

[0001] This application belongs to the field of interface testing technology, and in particular relates to an interface testing method, apparatus, device, storage medium and program product. Background Technology

[0002] In the field of software development and quality assurance, interfaces serve as the core carrier for data interaction between modules within a system and across systems. Their stability and reliability directly determine the operational quality of the entire software system. Therefore, interface testing has become a key link in the software testing system.

[0003] Currently, most existing API testing methods involve manually entering API parameters one by one and manually adjusting test cases, while maintaining API parameters and test cases is done through test management platforms, spreadsheets, and other similar methods. However, manually maintaining API information and test cases is not only inefficient but also costly. Summary of the Invention

[0004] This application provides an interface testing method, apparatus, device, computer storage medium, and program product, which can parse interface documents in real time and automatically update the marked interface status, while dynamically updating test cases, thereby improving test case generation efficiency and reducing maintenance costs.

[0005] In a first aspect, embodiments of this application provide a method for interface testing, the method comprising: During interface testing, upon receiving the Uniform Resource Locator (URL) of the interface document entered by the user in the interface interface, the interface document is generated based on the URL. The interface document includes the request addresses of all interfaces in the system. The system matches the request addresses of all interfaces with the request addresses of the interfaces stored in the interface library to obtain the matching results. Update the interfaces and their corresponding use cases in the interface list based on the matching results, and annotate the interfaces and their corresponding use cases. The target interface displays the list of interfaces and their corresponding use cases.

[0006] Secondly, embodiments of this application provide an interface testing apparatus, the apparatus comprising: The receiving module is used during interface testing to obtain the interface document generated based on the URL when the user inputs the URL of the interface document in the interface interface. The interface document includes the request addresses of all interfaces in the system. The matching module is used to match the request addresses of all interfaces in the system with the request addresses of interfaces stored in the interface library to obtain the matching results. The annotation module is used to update the interfaces and their corresponding test cases in the interface list based on the matching results, and to annotate the interfaces and their corresponding test cases. The display module is used to display information about the interfaces and their corresponding use cases in the interface list on the target interface.

[0007] Thirdly, embodiments of this application provide a terminal device, the device including: a processor and a memory storing computer program instructions; the processor executes the computer program instructions to implement the interface testing method as described in the first aspect.

[0008] Fourthly, embodiments of this application provide a computer storage medium on which computer program instructions are stored, and when the computer program instructions are executed by a processor, the interface testing method as described in the first aspect is implemented.

[0009] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform the interface testing method as described in the first aspect.

[0010] This application provides a method, apparatus, device, storage medium, and program product for interface testing. The method obtains interface information in real time by receiving a URL, eliminating the need for manual input of interface parameters. It matches the system interface request address with addresses stored in the interface library, updating the interface list and corresponding test cases based on the matching results. This achieves automated synchronization and maintenance of interface information, eliminating the need for testers to manually enter or update interface information. It automatically marks changes in interfaces, saving significant time and reducing interface maintenance costs. By annotating interfaces and corresponding test cases based on the matching results and uniformly displaying relevant information on the target interface, it integrates interface test case writing and maintenance. Testers can intuitively obtain the latest status information of interfaces and test cases on a single interface, reducing the possibility of human error and improving the efficiency and visibility of test case maintenance. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of the structure of the interface testing system provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the interface testing method provided in an embodiment of this application; Figure 3This is a flowchart illustrating the interface debugging process in the interface testing method provided in this application embodiment; Figure 4 This is a flowchart illustrating the interface verification process in the interface testing method provided in this application embodiment; Figure 5 This is a flowchart illustrating the modification of test cases in the interface testing method provided in this application embodiment; Figure 6 This is a flowchart illustrating the execution of test cases in the interface testing method provided in this application embodiment; Figure 7 This is a flowchart illustrating the interface testing system provided in this application embodiment; Figure 8 This is a schematic diagram of the interface testing apparatus provided in the embodiments of this application; Figure 9 This is a schematic diagram of the structure of the terminal device provided in the embodiments of this application. Detailed Implementation

[0013] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0014] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0015] In the current field of API automation testing, API automation testing tools are typically used to develop, maintain, and run test scripts. When developing API automation tests using existing tools, test scripts need to be written manually or recorded by hand, and then managed and maintained using test management platforms, Excel, or similar methods. API automation test scripts mainly include information such as API address, operation methods, test parameters, and test results.

[0016] Existing API testing tools on the market allow users to perform API testing locally. However, these tools require local software installation, environment configuration, and manual input of API parameters to execute tests. If team collaboration or personnel changes are needed, API scripts must be exported and transferred for information sharing, which is inconvenient for maintenance and management. Meanwhile, some API testing platforms under development integrate API testing technology and test case management, addressing the maintenance and management difficulties of testing tools. However, this solution relies on manual API maintenance through API documentation and cannot automatically detect additions or removals, requiring significant time and hindering automated maintenance and management.

[0017] Currently, most existing API testing methods involve manually entering API parameters one by one and manually adjusting test cases, while maintaining API parameters and test cases is done through test management platforms, spreadsheets, and other similar methods. However, manually maintaining API information and test cases is not only inefficient but also costly.

[0018] To address the problems of existing technologies, embodiments of this application provide a method, apparatus, device, storage medium, and program product for interface testing. This method obtains interface information in real time by receiving a URL, eliminating the need for manual input of interface parameters. It matches the system interface request address with addresses stored in an interface library, updating the interface list and corresponding test cases based on the matching results. This achieves automated synchronization and maintenance of interface information, eliminating the need for testers to manually enter or update interface information. It automatically marks changes in interfaces, saving significant time spent manually maintaining each interface and reducing interface maintenance costs. By annotating interfaces and corresponding test cases based on the matching results and uniformly displaying relevant information on the target interface, it integrates interface test case writing and maintenance. Testers can intuitively obtain the latest status information of interfaces and test cases on a single interface, reducing the possibility of human error and improving the efficiency and visibility of test case maintenance.

[0019] The embodiments of this application provide a method, apparatus, device, storage medium, and program product for interface testing. It adopts a front-end and back-end separation technical architecture. The front-end uses the Vue framework, the back-end uses the Django framework, the engine uses the Python language and the Flask framework, MySQL is used to store test projects, test cases, results, and other data, and Redis is used to store user session data.

[0020] The following section first introduces the interface testing system provided in the embodiments of this application.

[0021] Figure 1 A schematic diagram of the structure of an interface testing system 100 provided in one embodiment of this application is shown. Figure 1 As shown, the system may include: a user maintenance module 101, a project maintenance module 102, an environment maintenance module 103, an automated testing component 110, and an automated testing maintenance component 120; The automated testing component 110 includes: an import module 111, a debugging module 112, a parameter processing module 113, a logging module 114, a test case module 115, and a verification module 116.

[0022] The automated test maintenance component 120 includes: test case maintenance module 121, batch execution module 122, reference copying module 123, and data monitoring module 124.

[0023] Users log in via the web interface through the user maintenance module 101. This module calls the user information interface and the access control interface to achieve identity verification and access control, ensuring system data security. After logging in, users enter the target project. The project maintenance module 102 calls the project information interface to maintain the basic information of the project. At the same time, the environment maintenance module 103 configures services, environments and variables according to the project service requirements. Based on the one-to-many correspondence between projects and services, and services and environments, it realizes the multi-environment reuse and centralized maintenance of interface test cases.

[0024] The subsequent automated testing process is supported by the automated testing component 110 and the automated testing maintenance component 120: First, through the import module 111 of the automated testing component 110, the user inputs the URL of the API interface document. The system periodically or manually pulls and parses the interface information, matches it with the interface library, and completes the annotation and template generation for adding, deleting, and changing interfaces. Manual addition of interfaces is also supported. After generating the interface template, the user selects a local or remote engine to conduct interface debugging through the debugging module 112. The user fills in the verification parameters and submission parameters according to the rules. The verification module 116 generates a field position mapping table. The predicted and actual response parameters are compared in terms of type, value, and structure through the field position mapping table. At the same time, the log module 114 records the verification results.

[0025] After the interface debugging is successful, the test case module 115 allows users to combine multiple interfaces to generate test cases, configure pre-tool methods or post-tool methods, and select manual or batch scheduled execution methods and corresponding engines. During execution, the parameter processing module 113 extracts step-level variables and dynamically replaces variables according to the priority of step-level, test case-level, and environment-level. The log module 114 synchronously records the entire process log and historical log of test case execution.

[0026] The entire lifecycle maintenance of test cases is handled by the automated test maintenance component 120: the test case maintenance module 121 supports adding, deleting, modifying, and querying test cases; the reference and copy module 123 can reuse commonly used pre-processing steps; the batch execution module 122 completes large-scale test case scheduling and execution, generating a result list containing execution results and error information; finally, the data monitoring module 124 monitors and statistically analyzes the number of interfaces, the number of test cases, and execution results, generating daily or weekly summary reports to provide data support for test progress control and maintenance decisions.

[0027] The interface testing method provided in the embodiments of this application will be introduced first below.

[0028] Figure 2 A flowchart illustrating an embodiment of the interface testing method provided in this application is shown. Figure 2 As shown, the method may include the following steps: S201 to S204.

[0029] S201. During interface testing, upon receiving the Uniform Resource Locator (URL) of the interface document entered by the user on the interface interface, obtain the interface document generated based on the URL. The interface document includes the request addresses of all interfaces in the system.

[0030] During interface testing, the system can receive the URL of the interface documentation sent by the user through the client. The user enters the URL of the interface documentation through the interface interface of the client.

[0031] After receiving the URL of the interface document, the interface document is generated based on the URL, and during testing, the request addresses and other information of all interfaces in the system are stored in the interface document.

[0032] In some embodiments, the interface documentation may also include the request methods, request parameters and formats, and response results and formats for all interfaces of the system.

[0033] In some embodiments, obtaining the URL-based interface documentation may include: After configuring the URL of the API documentation, the system can retrieve the API documentation periodically or manually.

[0034] In some embodiments, upon receiving the Uniform Resource Locator (URL) of the interface document input by the user in the interface interface, generating the interface document based on the URL may include: Add an Application Programming Interface (API) dependency to the project and create a configuration class; generate API documentation based on the API dependency and configuration class; obtain the project URL, add a first suffix to the project URL to access the API documentation, and add a second suffix to the project URL to obtain the API documentation in text data exchange format.

[0035] By setting the API interface documentation to be automatically updated in real time along with the project code, no manual maintenance is required.

[0036] In one example, the first suffix can be " / API-ui.html", and the second suffix can be "project URL + / v2 / api-docs". Adding the second suffix to the project URL will retrieve the API documentation, which can be in JSON format.

[0037] In one example, a Swagger dependency is added to the project, and a configuration class is created; Generate Swagger API documentation based on Swagger dependencies and configuration classes; Get the project URL, add " / Swagger-ui.html" to the end of the project URL to access the Swagger API documentation, and add "+ / v2 / api-docs" to the end of the project URL to get the API documentation in JSON format.

[0038] The system generates Swagger API documentation that automatically updates in real-time along with the project code. This application only needs to retrieve the API documentation in real-time to obtain information about all system APIs, eliminating the need for manual maintenance. Furthermore, the Swagger API documentation adheres to the standard format used to define and describe RESTful APIs. By traversing the Swagger API documentation using keywords, the system ensures that the content has a standardized and consistent organizational logic. The system can efficiently and unambiguously traverse and retrieve API information from the documentation using keywords, guaranteeing the accuracy and compatibility of API information parsing. This provides a unified and reliable foundation for subsequent automated API import and test case generation processes, avoiding parsing failures or missing information due to inconsistent API documentation formats. Additionally, the Swagger documentation includes a built-in security authentication module to ensure the security of using the API documentation.

[0039] This application embodiment obtains the URL and, based on the URL, retrieves the interface document containing all interface request addresses of the system. This eliminates the need for local environment configuration and lays the foundation for subsequent interface testing operations.

[0040] In some embodiments, before obtaining the URL-based interface documentation, the method may include: When a user logs in via a client, the interfaces for obtaining user information and access control are provided. Access to the project is controlled via the access control interface; Configure services and environment information according to project requirements.

[0041] By configuring service and environment information according to project requirements, the test environment can be accurately adapted to the actual project scenario, avoiding test distortion caused by environment incompatibility, reducing adaptation workload and testing costs, while ensuring service call stability and data interaction security, providing reliable environment support for the entire interface testing process, and improving testing efficiency and result credibility.

[0042] In some embodiments, each project and service has a one-to-many correspondence, and services and environments have a one-to-many correspondence.

[0043] By setting up a one-to-many correspondence between services and environments, interface use cases can be reused across multiple environments, which is beneficial for centralized classification and maintenance.

[0044] S202, match the request addresses of all interfaces in the system with the request addresses of the interfaces stored in the interface library to obtain the matching results.

[0045] In some embodiments, matching the request addresses of all interfaces in the system with the request addresses of interfaces stored in the interface library to obtain matching results may include: Obtain the request addresses of all interfaces in the system and generate a list of system interface addresses; Retrieve all the API request addresses stored in the API library and generate a list of API addresses in the API library; Iterate through each request address in the system interface address list and match it character by character with the addresses in the interface library interface address list; The first matching result is obtained.

[0046] In some embodiments, iterating through each request address in the system interface address list and performing character-level matching between each address and the address in the interface library interface address list may include: When iterating through each request address in the system interface address list, for the currently iterated system interface request address, split the complete string of the current system request address by character; Iterate through each address in the list of API library addresses and split the complete string of the API library request address by character. Starting from the first character, the system request address and the interface library request address are compared character by character to check for consistency. If any character does not match, the system request address and the interface library request address are determined to be mismatched, and the process continues to match the next interface library request address. If all characters match exactly, the system request address and the interface library request address are determined to be matched, and the subsequent matching of the current system request address is stopped and the matching result is recorded. If no completely matching address is found after traversing all interface library request addresses in the interface address list, the current system request address is determined to have no match, and the matching process for the current system request address is completed, and the next request address in the system interface address list is processed.

[0047] The complete string can include protocol headers, domain name / IP address, port number, path, and parameters. Checking character consistency can include checking character content, order, and the position of special characters. Complete character consistency means that the character order and content of parameter key-value pairs are identical.

[0048] In some embodiments, the first matching result may include: The API library does not include the API request address; The API library includes the request addresses of the APIs; The API documentation does not include the request addresses in the API library; that is, the API library does not include the APIs in the API documentation.

[0049] In some embodiments, where the interface library includes the request address of the interface, it may further include: Retrieve the first remaining interface information of the interface corresponding to the request address in the interface documentation. The remaining interface information may include the request method, request parameters and format, and response result and format. Retrieve the second remaining interface information of the interface corresponding to the requested address in the interface library. The remaining interface information may include the request method, request parameters and format, and response result and format. Perform character-level matching on the first and second remaining interface information; The second matching result is obtained.

[0050] In some embodiments, character-level matching of the first remaining interface information and the second remaining interface information may include: The first and second remaining interface information are split according to information categories, which can be based on information categories such as request method, request parameters and format, and response result and format. Perform character-level matching for each category sequentially; Integrate the character matching results of all information categories. If all characters in all categories match completely, then determine that the first remaining interface information and the second remaining interface information will match. If there are character differences in any category, then mark it as a mismatch and record the specific difference location and content.

[0051] In some embodiments, performing character-level matching sequentially for each category may include: Match the request method, extract the request method string from the first remaining interface information and the second remaining interface information, and compare the character content and length character by character starting from the first character. If there are inconsistent characters or different lengths, mark the request method as mismatched, otherwise mark it as matched.

[0052] Match the request parameters and format, split the request parameters and format content in the first and second remaining interface information by character, check the consistency of the character sequence character by character, and record the character differences.

[0053] Match the response results and format by comparing the response field names, data types, hierarchical structure descriptions, and format rules in the first and second remaining interface information character by character, and checking whether the positions of special symbols and character content are completely consistent.

[0054] Splitting by character can include splitting by parameter name, data type, constraint, or format symbol.

[0055] Character differences can include the number of parameters, parameter names, and character differences in the format definition.

[0056] Special symbols can include colons or curly braces.

[0057] In some embodiments, the second matching result may include: The API library includes the request address of the API, and the API request method, request parameters, or group fields or structure of the response result may change. The API library includes the API request address, and the API request method, request parameters, or response result group fields or structure remain unchanged.

[0058] In some embodiments, the matching results may include a first matching result and a second matching result.

[0059] This application embodiment accurately obtains the address matching results by matching all interface request addresses of the system with the interface request addresses stored in the interface library one by one. This provides a core judgment basis for subsequent updates of interfaces and corresponding test cases, effectively identifies the differences between the interface addresses in the interface library and the current system interface addresses, and reduces the possibility of test omissions due to undetected interface address changes.

[0060] S203, update the interfaces and their corresponding use cases in the interface list based on the matching results, and annotate the interfaces and their corresponding use cases.

[0061] If the matching result indicates that the interface library does not include the request address of the interface, generate an interface template, add the interface to the interface list, and add interface annotations to the interface.

[0062] If the matching results indicate that the interface library includes the request address of the interface, and the request method, request parameters, or group fields or structure of the response result have changed, the request method, request parameters, group fields or structure fields of the response result will be marked in the interface list, and the corresponding use cases will also be marked.

[0063] The matching results indicate that the interface library does not include the interfaces in the interface documentation. The interface is marked in the interface list, and the use cases for calling that interface are also marked.

[0064] This application embodiment achieves dynamic updates of the interface list and corresponding test cases through matching results, which can automatically handle the addition and deletion of interfaces. Testers do not need to manually enter or maintain interface and test case information, which greatly saves manual maintenance time and reduces maintenance costs. At the same time, by annotating the interfaces and corresponding test cases, the status of the interfaces and test cases is clearly distinguished, which provides clear guidance for subsequent test execution and maintenance, and reduces problems caused by untimely communication between development and testing.

[0065] In some embodiments, labeling interfaces and their corresponding use cases may include: Different colors are used to label the interfaces and their corresponding use cases.

[0066] In one example: if the matching result indicates that the interface library does not include the request address of the interface, the interface is determined to be an interface to be added, and the interface to be added is marked with the first color; If the matching results indicate that the interface library does not include the interface in the interface document, the interface is determined to be an interface to be deleted, and the interface to be deleted and the corresponding use case are marked with the second color; If the matching results indicate that the interface library includes the request address of the interface, and the request method of the interface has changed, or the request parameters have changed, or the group fields or structure of the response result have changed, then the interface is determined to be an interface to be modified, and the interface to be modified and the corresponding use cases are marked with the third color.

[0067] S204 Displays information about the interfaces and their corresponding use cases in the interface list on the target interface.

[0068] In some embodiments, the target interface is a visual interactive interface developed based on the Vue framework, used to display a list of interfaces and corresponding test case information.

[0069] The Vue framework can break down functions such as displaying the API list, viewing test case details, and status annotation into independent reusable components. When iterating the test interface, there is no need to refactor the entire system, which improves development and maintenance efficiency, makes team collaboration smoother, and significantly reduces labor costs. The efficient two-way data binding feature allows API status updates and test case information modifications to be synchronized to the interface in real time. Testers can obtain the latest data without manually refreshing, reducing operation time and avoiding repetitive work caused by information lag.

[0070] This application embodiment achieves visual integration and centralized management of interface and test case information by centrally displaying the interface list and corresponding test case information on the target interface. This not only allows testers to intuitively obtain basic interface information and related test case details on the same interface without switching between multiple pages or tools, but also enables them to quickly grasp the correspondence between the two, reducing the time cost of information search, clearly presenting the latest status of interfaces and test cases, reducing omissions or misjudgments caused by information dispersion, reducing human operation errors, and ensuring the continuity and accuracy of testing work.

[0071] In some embodiments, the interface testing method may further include: Record all log information from steps S201 to S204; A summary report is generated based on the log information.

[0072] By recording all log information from S201 to S204 and generating a summary report, the summary report provides traceable evidence, making it easier for testers to quickly locate abnormal links and reduce the time spent troubleshooting. The summary report generated based on the logs can intuitively present the data of the entire process, such as interface document parsing, address matching, and information matching, helping the team to efficiently grasp the overall status of interface maintenance and provide data support for subsequent interface debugging and maintenance.

[0073] The abnormal process may include reasons for address matching failure and differences in interface information matching.

[0074] This application embodiment can obtain a document containing all interface request addresses of the system via URL, efficiently completing the collection and synchronization of interface information; through one-by-one matching of interface addresses with the interface library, accurate verification of interface information is achieved; based on the matching results, interfaces and corresponding test cases are updated and labeled to ensure the relevance and timeliness of interfaces and test cases; finally, relevant information is uniformly displayed on the target interface, providing testers with an intuitive and centralized operation entry point, improving the clarity and convenience of interface and test case maintenance, while reducing manual intervention and lowering time costs.

[0075] In some embodiments, updating the interfaces and their corresponding use cases in the interface list based on the matching results, and annotating the interfaces and their corresponding use cases, may include: If the matching result indicates that the interface library does not include the request address of the interface, generate an interface template, add the interface to the interface list, and add interface annotations to the interface.

[0076] In some embodiments, when the matching result indicates that the interface library does not include the request address of the interface, generating an interface template may include: Obtain information about newly added interfaces and the system's preset interface template framework; The information of the newly added interface is filled into the system's preset interface template framework to generate the interface template.

[0077] In some embodiments, the interface template includes a request method, a request address, request parameters, and a response result.

[0078] In some embodiments, when the request parameters and response results for generating the interface template are in JSON format, the format of each field is "field name": "^field type".

[0079] This application's embodiments clarify the specific handling methods when the target interface is missing from the interface library, reducing the possibility of omissions or incorrect parameter input due to manual interface addition. When the matching results show that the interface library does not contain the interface request address, the system automatically generates an interface template, adds the interface, and adds annotations, eliminating the need for testers to manually write interface information. This automated template generation method not only ensures the completeness and standardization of interface information, reducing the possibility of omissions caused by manual input, but also clearly marks the addition status through interface annotations, making it convenient for testers to quickly locate the new interface, reducing the time cost of subsequent debugging and maintenance, and solving the defect that some platforms under development cannot automatically detect newly added interfaces.

[0080] In some embodiments, such as Figure 3 As shown, after generating the interface template, the method may also include: S301 to S303.

[0081] S301 receives the first input from the user to select debugging, which includes information on whether to debug remotely or locally.

[0082] It can receive the first input for selecting debug sent by the user through the client, whereby the user inputs the first input for selecting debug through the client's interface.

[0083] In some embodiments, receiving the first input from the user selecting debugging may include: In the system's interface, you can set up an entry point to select the debugging type: remote debugging or local debugging. Receive the first input triggered by the user selecting an entry point through the interface interface via the client; Parse the debugging type information in the first input. If remote debugging is selected, load the preset remote environment configuration; if local debugging is selected, guide the user to configure the local service address and pass the debugging type selection result to the backend.

[0084] This application embodiment provides a flexible operation mode for interface debugging that adapts to different scenarios by receiving a first input from the user that includes the option of remote debugging or local debugging. Users can choose the debugging method according to the actual test environment requirements without being limited to a single debugging mode. This satisfies the need for rapid debugging in a local environment and also supports cross-scenario testing and verification in a remote environment, improving the adaptability and convenience of interface debugging. At the same time, it reduces the complexity of debugging environment configuration, allowing users with different operational needs to carry out interface debugging work efficiently.

[0085] S302, receive the user's second input, which includes verification parameters and submission parameters; wherein the verification parameters are parameters entered by the user based on the displayed interface template, and the submission parameters are parameters entered by the user based on debugging requirement information.

[0086] It can receive a second input for debugging sent by the user through the client, whereby the user inputs the second input through the client's interface.

[0087] In some embodiments, verification parameters are parameters entered by the user based on the interface's basic information requirements after the interface template displays the basic interface information. Submission parameters are parameters entered by the user in conjunction with the specific debugging scenario; these are the request parameters actually sent to the client during interface debugging.

[0088] In some embodiments, the verification parameters may include request parameter format or response field rules; the submission parameters may include the username or ID required by the input interface.

[0089] This application embodiment fully collects the two types of key parameters required for interface debugging by receiving verification parameters and submission parameters. It not only relies on the interface template to ensure the standardization of parameters, but also meets the personalized parameter configuration requirements in combination with debugging needs, providing comprehensive and accurate data support for interface verification.

[0090] S303 verifies the interface based on verification parameters and submission parameters to complete the debugging of the interface.

[0091] In some embodiments, validating the interface based on verification parameters and submission parameters may include: Retain the parameters that need to be verified or submitted; Delete parameters that do not need to be validated or submitted; In some embodiments, retaining the value that needs to be validated or submitted may include: If field values ​​need to be validated or submitted, then the field values ​​should be retained. If field types need to be validated or submitted, then the field types should be retained; If you need to retrieve variables from the results and store them as step-level variables, then preserve the string.

[0092] In some embodiments, while preserving the string, it is possible to read certain bits from a string.

[0093] When preserving strings, it supports reading specific numbers from a string, which can meet complex variable extraction needs, accurately obtain the required step-level variables, and improve the flexibility and targeting of variable extraction.

[0094] In some embodiments, validating the interface based on verification parameters and submission parameters may further include: Read the values ​​of the predicted response parameters and the actual response parameters; Verification is performed based on the predicted response parameter values ​​and the actual response parameter values.

[0095] In some embodiments, verification based on the values ​​of the predicted response parameters and the actual response parameters may include: If the value obtained from the predicted response parameter is of field type, validate the field type; When the predicted response parameter is a field value, both the field type and the field value are validated. If the predicted response parameter is a string, the string is not validated, and the corresponding actual response parameter value is stored in the step-level variable list.

[0096] If the actual response parameter value is not found, search within the same level. If it is also not found within the same level, log an error.

[0097] The embodiments of this application verify the interface based on verification parameters and submission parameters, which can effectively verify the functional effectiveness, parameter adaptability and response accuracy of the interface in a specified environment, promptly identify problems in the interface, achieve the goal of interface debugging, and improve the efficiency and reliability of interface testing.

[0098] This application's embodiments, based on the generated interface template, add flexible debugging methods and parameter input methods, providing both remote and local debugging options. Users can choose according to their needs, especially with remote debugging reducing local deployment and configuration, and decreasing dependence on the local environment. Simultaneously, by receiving verification and submission parameters input by users based on the interface template, users can configure verification content as needed, improving verification flexibility. Combining parameter verification with interface debugging ensures targeted debugging while reducing the possibility of debugging errors due to improper parameter configuration, thus improving the efficiency and accuracy of interface debugging.

[0099] In some embodiments, such as Figure 4 As shown, the interface is validated based on the verification parameters and submission parameters, which may include: S401 to S403.

[0100] S401, Read all field names of the predicted response parameters, which include validation parameters and submission parameters; In some embodiments, reading all field names of the predicted response parameters may include: Get the verification parameters and submission parameters; The validation and submission parameters are parsed into an iterable key-value pair / nested structure; Starting from the top level of the validation parameters and submission parameters, traverse layer by layer and extract the field names of each level; When encountering nested substructures, the process recursively enters the substructure to extract all subfield names and the hierarchical path information of each field. Integrate the field names from all levels to form a complete list of field names, thus completing the reading of all field names for the predicted response parameters.

[0101] This application embodiment comprehensively obtains the core field basic information required for interface debugging and verification by reading all field names of the predicted response parameters, which include verification parameters and submission parameters. This lays a complete data foundation for subsequent field hierarchy judgment, parameter value extraction, and type and value verification, ensuring that no field is omitted during the verification process.

[0102] S402, when the field name is a multi-level field, generate a field position mapping table; In some embodiments, when the field name is a multi-level field, generating a field position mapping table may include: Retrieve the field names and hierarchical path information of multi-level fields; Determine the specific location coordinates of each field in the predicted response parameter structure based on the hierarchical path information; Construct a mapping between field names and location coordinates based on location coordinates; Based on this correspondence, a standardized field location mapping table is generated, which includes field names, hierarchical paths, location coordinates, etc.

[0103] This application's embodiments generate a field position mapping table for the complex scenario of multi-level fields, clearly defining the specific positional relationship of multi-level fields in the parameter structure. This solves the problem of ambiguous positions and difficulty in accurate positioning caused by nesting of multi-level fields, and provides a standardized positioning basis for the accurate extraction of the corresponding values ​​of the predicted response parameters and the actual response parameters.

[0104] S403, obtain the values ​​of the positions corresponding to the predicted response parameters and the actual response parameters based on the field position mapping table; this value is used to characterize the validation of the field type and / or value.

[0105] In some embodiments, the values ​​of the positions corresponding to the predicted response parameters and the actual response parameters are obtained based on a field position mapping table; these values ​​are used to characterize the validation of field types and / or values, and may include: When both the predicted response parameters and the actual response parameters contain field types, the field types of the predicted response parameters and the field types of the actual response parameters are validated. When both the predicted response parameters and the actual response parameters contain field values, the field values ​​of the predicted response parameters and the field values ​​of the actual response parameters are validated. When the predicted response parameter contains field types and the actual response parameter contains field values, the values ​​of the corresponding positions of the predicted response parameter and the actual response parameter are obtained according to the field position mapping table, and the values ​​of the predicted response parameter and the actual response parameter are verified. When the predicted response parameter contains field values ​​and the actual response parameter contains field types, the values ​​of the corresponding positions of the predicted response parameter and the actual response parameter are obtained according to the field position mapping table, and the values ​​of the predicted response parameter and the actual response parameter are verified.

[0106] This application provides direct comparative data support for the field type and field value validation of interface parameters, ensuring that the validation work can focus on core data, improving the accuracy and pertinence of parameter validation, and avoiding validation errors caused by field position confusion.

[0107] This application embodiment reads all field names of the predicted response parameters, generates a field position mapping table for multi-level fields, and then obtains the values ​​corresponding to the predicted and actual response parameters based on this mapping table, achieving accurate verification of field types and / or values. This verification method overcomes the limitations of only supporting assertions, regular expression matching, or single-field verification. It can handle both single-level fields and complex scenarios with multi-level fields, while simultaneously addressing the dual verification requirements of field types and values. This significantly improves the comprehensiveness and accuracy of verification, reduces the possibility of missing interface issues due to insufficient verification capabilities, and meets the automated testing needs in complex scenarios.

[0108] In some embodiments, updating the interfaces and their corresponding use cases in the interface list based on the matching results, and annotating the interfaces and their corresponding use cases, may include: If the matching results indicate that the interface library includes the request address of the interface, and the request method, request parameters, or group fields or structure of the response result have changed, the request method, request parameters, group fields or structure fields of the response result will be marked in the interface list, and the corresponding use cases will also be marked.

[0109] In some embodiments, the group fields or structure fields of the request method, request parameters, and response results are labeled in the interface list, and the use cases corresponding to the interfaces are also labeled, which may include: Retrieve the matching results and the original interface information stored in the interface library; The comparison results are obtained by comparing the original interface information with the current interface information of the system. Based on the comparison results, the original interface information stored in the interface library is annotated to obtain the annotated interface library interfaces; Based on the annotated interface library interface, associate and annotate the use cases corresponding to that interface.

[0110] In some embodiments, comparing the original interface information with the current system interface information may include: Compare whether the request method has changed, whether the request parameters have changed, and whether the group fields or structure of the response result have changed.

[0111] In some embodiments, the interface information to be changed may include the request method, request parameters, and group fields / structure fields of the response result.

[0112] In some embodiments, annotating the original interface information stored in the interface library based on the comparison results may include: identifying the change type or highlighting the difference fields in the original interface information stored in the interface library.

[0113] In some embodiments, associating and labeling the use cases corresponding to the interface may include labeling the use cases corresponding to the interface with an adaptation flag or an update flag.

[0114] This application's embodiments address the shortcomings of existing development platforms that cannot automatically detect interface changes and require manual modification by focusing on scenarios involving interface information changes. When the matching results show that the interface address exists but the request method, parameters, or response result fields / structure have changed, the system will categorize and annotate the changed content in the interface list and simultaneously annotate the corresponding interface test cases. This annotation allows testers to quickly locate the change points without having to compare interface documents and old test cases one by one, reducing the time cost of change identification. Simultaneously, the annotation of changed test cases facilitates targeted adjustments by testers, preventing test cases from becoming invalid due to untimely synchronization of interface changes, further reducing test case maintenance costs and improving the timeliness of interface testing.

[0115] In some embodiments, updating the interfaces and their corresponding use cases in the interface list based on the matching results, and annotating the interfaces and their corresponding use cases, may include: The matching results indicate that the interface library does not include the interfaces in the interface documentation. The interface is marked in the interface list, and the use cases for calling that interface are also marked.

[0116] In some embodiments, if the matching result indicates that the interface library does not include the interfaces in the interface documentation, and the interface is annotated in the interface list, and the use cases for calling that interface are annotated, it may include: Retrieve matching results and interface information from the API library; Based on the matching results, a confirmation result is obtained, which indicates that the interface library does not include the interfaces in the interface documentation. Based on the confirmation results, the interfaces in the interface library that are not included in the interface document are annotated to obtain the interface annotation results; Based on the interface annotation results, associate and annotate the corresponding call test cases for the interface.

[0117] This application addresses the scenario where an interface exists in the interface library but is missing from the interface documentation. It supplements the annotation rules to solve the problem of redundant interfaces and test cases being difficult to discover and causing maintenance chaos in existing technologies. When the matching result indicates that the interface exists in the interface library but is missing from the documentation, the system will annotate the interface and its corresponding call test cases, clearly marking redundant or invalid interface resources. This allows testers to quickly identify interfaces and test cases that do not need to be retained, avoiding redundant resources occupying storage and maintenance effort, and solving the problems of difficult interface and test case cleanup and cumbersome maintenance in traditional tools.

[0118] In some embodiments, such as Figure 5As shown, after the target interface displays the interface list and the information of the corresponding use cases, the method may also include: S501 to S502.

[0119] S501, receive user selection input based on annotations, the selection input includes deleting the annotation interface and the corresponding use case, or retaining the annotation interface and the corresponding use case; It can receive annotation-based selection input sent by users through the client, where users input annotation-based selection input through the client's interface.

[0120] In some embodiments, receiving user selection input based on annotations, whereby the selection input includes deleting the annotated interface and its corresponding use case, or retaining the annotated interface and its corresponding use case, may include: Retrieve the status information of the interfaces and corresponding use cases that are marked in the interface list; Based on the status information, the system's interface will display the options for deletion and retention; Extract selection input information based on the selection operation triggered by the user on the interface through the user terminal; Based on the selected input information, the user's processing instructions for the labeled interface and corresponding use cases are parsed.

[0121] This application embodiment grants users the right to independently maintain the annotated interfaces and use cases by receiving user selection input based on annotation information, clarifying the user's processing intentions for interfaces in different states, and providing direct instruction basis for subsequent deletion or retention operations, ensuring that the operation accurately matches the user's needs.

[0122] S502, in response to the selected input, executes the deletion or retention of the labeled interface and the corresponding use case.

[0123] In some embodiments, responding to a selection input by deleting or retaining the labeled interface and its corresponding use case may include: Obtain the user's selection input information; The user's operation command type is parsed from the selected input information; Process the interface and its corresponding use case according to the type of operation instruction.

[0124] In some embodiments, processing the interface and its corresponding use case according to the operation instruction type may include: When the operation instruction type is a delete instruction, the database records of the labeled interface and its corresponding test case will be deleted, and the labeled interface and its corresponding test case will be removed from the list display. When the operation instruction type is a reserved instruction, the status of the labeled interface and the corresponding use case is locked, and the data of the labeled interface and the corresponding use case is saved.

[0125] In some embodiments, the operation instruction type may include: a delete instruction or a retain instruction.

[0126] In this embodiment, the corresponding operation is executed in response to the user's selection input. If the user chooses to delete, redundant marked interfaces and invalid test cases are cleaned up in the interface list, simplifying the interface library and test case library, reducing resource consumption and improving maintenance efficiency. If the user chooses to retain, the association status of the interface and test cases is maintained, preserving the data foundation for subsequent operations such as supplementing documentation, adapting changes, and verifying test cases, realizing the flexibility and targeting of interface and test case management, and ensuring the orderly progress of the interface testing process.

[0127] This application's embodiment, based on the labeled redundant interface, adds a user-selectable deletion or retention mechanism, balancing the needs of automated management with flexible manual control. By receiving user input based on labeled selections and responding to execute deletion or retention operations, the risk of accidental deletion that may occur during automatic system cleanup is reduced.

[0128] In some embodiments, the method may further include: Receive a third input from the user, which includes information on a combination of multiple interface selections; It can receive third input sent by the user through the client, where the user inputs the third input through the client's interface.

[0129] In some embodiments, receiving a third user input, which includes combined selection information for multiple interfaces, may include: Retrieve information for all selectable interfaces from the platform's interface list; Based on the interface information, display multiple interface selection interactive components on the interface interface; The action is selected based on the combination of the interface captured by the user's operation behavior in the interactive component; Extract identification information for multiple interfaces based on the selected action; The third input is formed by integrating the identification information and including multiple interface combination selection information.

[0130] In some embodiments, the multi-interface selection interaction component may include: checkboxes and batch selection lists.

[0131] In some embodiments, the identification information may include the interface ID and the interface name.

[0132] This application embodiment supports users to independently select target interfaces based on test scenario requirements by receiving a third input containing multiple interface combination selection information from the user. This breaks the independent testing limitation of a single interface test case, provides a selection basis for the subsequent combination and association of multiple interface test cases, and at the same time gives users the flexibility and autonomy in test case construction, adapting to the needs of multi-interface linkage testing in complex business scenarios.

[0133] In response to the third input, test cases are obtained by combining the test cases corresponding to multiple interfaces.

[0134] In some embodiments, combining test cases corresponding to multiple interfaces to obtain test cases may include: Obtaining third-party input from the user; The selected interface identifiers are parsed from the third input; Retrieve the associated use case set corresponding to each interface based on the interface identifier; Target use cases that conform to multi-interface linkage logic are filtered based on the use case set to obtain the filtering results; Based on the screening results, the target use cases are integrated according to preset combination rules to obtain the integrated result; Based on the integration results, test cases containing multi-interface linkage logic are generated.

[0135] In some embodiments, filtering target use cases that conform to multi-interface linkage logic based on the use case set may include filtering use cases by business process sequence and parameter passing relationship.

[0136] In some embodiments, the preset combination rules may include the order of use case execution and the parameter mapping configuration between interfaces.

[0137] This application embodiment integrates scattered individual interface test cases into test cases combining multiple interfaces, realizing flexible reuse and scenario-based combination of test case resources. Users do not need to manually write test cases related to multiple interfaces, which greatly reduces the complexity and workload of test case construction, while ensuring that the combined test cases can fit the interaction logic of multiple interfaces in the actual business process.

[0138] Test the test cases and obtain the test results.

[0139] This application embodiment, by testing the combined test cases and outputting test results, can efficiently verify the functional integrity, data consistency, and interface compatibility in multi-interface combination scenarios, promptly discover linkage issues that cannot be exposed in individual interface testing, provide comprehensive verification support for the stability of multi-interface collaborative business, and improve the coverage and effectiveness of interface testing.

[0140] This application embodiment receives user input for a combination of multiple interfaces, integrates the test cases corresponding to these interfaces into a complete test case, and then executes the test to obtain the results. This combined test case construction method eliminates the need for testers to write complex test cases from scratch, improving test case construction efficiency; at the same time, it allows for flexible combination of different interfaces according to project needs, adapting to diverse business scenario testing requirements.

[0141] In some embodiments, such as Figure 6As shown, the test cases are tested to obtain test results, which may include: S601 to S603.

[0142] S601, execute the test case.

[0143] In some embodiments, executing test cases may include: Receive a fourth input from the user, which includes information on whether to execute remotely or locally; Receive a fifth input from the user, which may include single-item execution or batch execution.

[0144] In the case of executing a test case individually, if an error occurs in a certain execution step, the execution of the test case will be stopped; if it is determined that the test case execution is incorrect, an error log will be printed.

[0145] When executing test cases in batches, if a test case fails, it is re-executed. If the test case still fails, an error log is printed, and the next test case is executed.

[0146] By implementing differentiated execution strategies for single-item and batch test case execution scenarios, single-item execution stops execution immediately upon encountering an error at any step, and an error log is printed after an error is detected. This allows for quick location of problem nodes, avoids invalid execution, and preserves evidence for troubleshooting. In batch execution, if a test case fails, it is retried. If the retry also fails, an error log is printed, and the next test case is executed. This approach improves test accuracy by eliminating occasional failures through retries while ensuring uninterrupted batch testing. Overall, it balances the precise troubleshooting needs of manual testing with the efficiency and continuity of batch testing, and facilitates subsequent issue tracing.

[0147] This application embodiment triggers the actual operation process of multiple interfaces in linkage by executing the combined test cases, simulating the interaction logic of interfaces in real business scenarios, providing a real execution data foundation for subsequent variable extraction and dynamic replacement, and directly verifying the executability of the test cases. It is the core execution link for realizing multi-interface linkage testing.

[0148] S602, extract step-level variables, use case-level variables, and environment-level variables during the execution process; In some embodiments, step-level variables are variables that take effect within a single execution step of a test case. Their scope is limited to that specific step and does not affect other steps. These variables are typically used to store temporary data for the current step, supporting the logical execution of the single-step operation.

[0149] Test case level variables are variables that take effect throughout the entire execution cycle of a single test case. Their scope covers all execution steps of the test case and are used to achieve data linkage between steps.

[0150] Environment-level variables are variables that take effect globally in the current test environment. Their scope covers all projects and all test cases in this environment, and they are often used to store general configuration information related to the environment.

[0151] In some embodiments, extracting step-level variables, use case-level variables, and environment-level variables during execution may include: Obtain the execution flow logs and runtime context data of the test cases; Locate the key nodes in the execution steps of each interface based on the execution process log; Extract step-level variables based on key nodes; Extract test case-level variables based on the global configuration information of the test cases; Extract environment-level variables based on the current debugging environment's configuration data.

[0152] This application embodiment comprehensively captures key dynamic data during test execution by extracting step-level variables, test case-level variables, and environment-level variables during the execution process. This avoids distortion of test results due to missing variables and provides complete and accurate data support for subsequent dynamic variable replacement, ensuring that the test results reflect the actual operating status.

[0153] S603 dynamically replaces step-level variables, test case-level variables, and environment-level variables to obtain test results.

[0154] In some embodiments, dynamically replacing step-level variables, use case-level variables, and environment-level variables may include: Retrieve the extracted set of step-level variables, use case-level variables, and environment-level variables; Based on the variable set, analyze the scope of application and association rules of various variables; The priority of dynamic variable replacement is determined based on the scope of application and association rules; The actual values ​​of the corresponding variables are substituted into the placeholders according to the replacement priority. Verify the completeness and accuracy of variable substitutions to ensure no omissions or incorrect substitutions.

[0155] In some embodiments, the priority of dynamic variable replacement is as follows: step-level variables; if no step-level variables are read, use case-level variables are read; if no use case-level variables are read, environment-level variables are read.

[0156] In one example, the step-level variable is "#{variable name}". When applying a step-level variable, the format of the step-level variable is "${variable name}". During the execution of the test case, when the parameter read matches "${", the variable name is used to read the variable. After reading the variable, the variable value is replaced with "${variable name}", and the test case continues to be executed.

[0157] This application's embodiments eliminate the difference between static variable configuration and actual execution scenarios by dynamically replacing three types of variables. This ensures that the test results are accurate outputs based on the real execution environment and dynamic parameters. It not only solves the problem of variable incompatibility under different environments and execution steps, but also improves the authenticity, reliability, and reference value of the test results, providing an accurate basis for problem localization and interface optimization in multi-interface linkage scenarios.

[0158] This application refines the execution flow of combined test cases and introduces a dynamic variable replacement mechanism, solving the problems of low flexibility and repeated modifications required to adapt to different scenarios in traditional test cases. When executing test cases, three types of variables—step-level, test case-level, and environment-level—are extracted and dynamically replaced, allowing test cases to adapt to different test scenarios and environments.

[0159] In one example, by replacing environment-level variables, the same test case can be reused in multiple environments such as development and testing without manually modifying parameters. By passing step-level variables, data linkage between test case steps is achieved, improving the consistency and adaptability of test cases. This dynamic variable replacement mechanism significantly reduces the cost of writing and modifying test cases, while increasing the reusability of test cases, further meeting the testing needs of rapidly iterating projects.

[0160] The complete process of the interface testing system provided in the embodiments of this application will be described below.

[0161] Figure 7 A flowchart illustrating an interface testing system 100 according to an embodiment of this application is shown. Figure 7 As shown, users first log in via the web interface, then proceed to the service configuration stage and provide environment information to complete the service configuration. Next, they enter the target interface by automatically importing the interface or manually adding the interface. Then, they select a local engine or a remote engine to debug the interface, with data monitoring synchronized during the debugging process. After the interface debugging is completed, test cases are generated by combining environment variables, test case variables, and step variables. The test cases are then debugged using the local engine or a remote engine. After successful debugging, the test cases are run manually or automatically, with data monitoring also synchronized during the execution process. Finally, a test report is generated, and the process results are fed back to the initial stage.

[0162] Figure 6An interface testing apparatus 700 provided in an embodiment of this application is shown. The apparatus may include: The receiving module 701 is used to obtain the interface document generated based on the URL when the user inputs the Uniform Resource Locator URL of the interface document in the interface interface during the interface testing process. The interface document includes the request addresses of all interfaces in the system. The matching module 702 is used to match the request addresses of all interfaces in the system with the request addresses of the interfaces stored in the interface library to obtain the matching results. The annotation module 703 is used to update the interfaces and their corresponding use cases in the interface list based on the matching results, and to annotate the interfaces and their corresponding use cases. Display module 704 is used to display information about the interfaces in the interface list and the corresponding use cases of the interfaces on the target interface.

[0163] This application embodiment can obtain a document containing all interface request addresses of the system via URL, efficiently completing the collection and synchronization of interface information; through one-by-one matching of interface addresses with the interface library, accurate verification of interface information is achieved; based on the matching results, interfaces and corresponding test cases are updated and labeled to ensure the relevance and timeliness of interfaces and test cases; finally, relevant information is uniformly displayed on the target interface, providing testers with an intuitive and centralized operation entry point, improving the clarity and convenience of interface and test case maintenance, while reducing manual intervention and lowering time costs.

[0164] In some embodiments, the device may further include: A new processing module has been added to the interface. When the matching result indicates that the interface library does not include the request address of the interface, the module generates an interface template, adds the interface to the interface list, and adds interface annotations to the interface.

[0165] This application's embodiments clarify the specific handling methods when the target interface is missing from the interface library, reducing the possibility of omissions or incorrect parameter input due to manual interface addition. When the matching results show that the interface library does not contain the interface request address, the system automatically generates an interface template, adds the interface, and adds annotations, eliminating the need for testers to manually write interface information. This automated template generation method not only ensures the completeness and standardization of interface information, reducing the possibility of omissions caused by manual input, but also clearly marks the addition status through interface annotations, making it convenient for testers to quickly locate the new interface, reducing the time cost of subsequent debugging and maintenance, and solving the defect that some platforms under development cannot automatically detect newly added interfaces.

[0166] In some embodiments, the device may further include: The debug type receiving module is used to receive the user's first input for selecting debug mode, which includes information on whether it is remote debug or local debug. The parameter receiving module is used to receive the user's second input, which includes verification parameters and submission parameters; the verification parameters are the parameters entered by the user based on the displayed interface template, and the submission parameters are the parameters entered by the user based on debugging requirements information. The parameter validation module is used to validate the interface based on the validation parameters and submission parameters in order to complete the debugging of the interface.

[0167] This application's embodiments, based on the generated interface template, add flexible debugging methods and parameter input methods, providing both remote and local debugging options. Users can choose according to their needs, especially with remote debugging reducing local deployment and configuration, and decreasing dependence on the local environment. Simultaneously, by receiving verification and submission parameters input by users based on the interface template, users can configure verification content as needed, improving verification flexibility. Combining parameter verification with interface debugging ensures targeted debugging while reducing the possibility of debugging errors due to improper parameter configuration, thus improving the efficiency and accuracy of interface debugging.

[0168] In some embodiments, the device may further include: The field name reading module is used to read all field names of the predicted response parameters, which include validation parameters and submission parameters. The mapping table generation module is used to generate a field position mapping table when the field name is a multi-level field. The field value acquisition module is used to obtain the values ​​of the positions corresponding to the predicted response parameters and the actual response parameters based on the field position mapping table; these values ​​are used to characterize the validation of field types and / or values.

[0169] This application embodiment reads all field names of the predicted response parameters, generates a field position mapping table for multi-level fields, and then obtains the values ​​corresponding to the predicted and actual response parameters based on this mapping table, achieving accurate verification of field types and / or values. This verification method overcomes the limitations of only supporting assertions, regular expression matching, or single-field verification. It can handle both single-level fields and complex scenarios with multi-level fields, while simultaneously addressing the dual verification requirements of field types and values. This significantly improves the comprehensiveness and accuracy of verification, reduces the possibility of missing interface issues due to insufficient verification capabilities, and meets the automated testing needs in complex scenarios.

[0170] In some embodiments, the device may further include: The interface test case update annotation module is used to annotate the request method, request parameters, or group fields or structure fields of the response result in the interface list when the matching result indicates that the interface library includes the request address of the interface and the request method, request parameters, or group fields or structure fields of the response result have changed, and to annotate the test cases corresponding to the interface.

[0171] This application's embodiments address the shortcomings of existing development platforms that cannot automatically detect interface changes and require manual modification by focusing on scenarios involving interface information changes. When the matching results show that the interface address exists but the request method, parameters, or response result fields / structure have changed, the system will categorize and annotate the changed content in the interface list and simultaneously annotate the corresponding interface test cases. This annotation allows testers to quickly locate the change points without having to compare interface documents and old test cases one by one, reducing the time cost of change identification. Simultaneously, the annotation of changed test cases facilitates targeted adjustments by testers, preventing test cases from becoming invalid due to untimely synchronization of interface changes, further reducing test case maintenance costs and improving the timeliness of interface testing.

[0172] In some embodiments, the device may further include: The missing interface annotation module indicates that the interface library does not include the interface in the interface documentation. It annotates the interface in the interface list and annotates the use cases for calling that interface.

[0173] This application addresses the scenario where an interface exists in the interface library but is missing from the interface documentation. It supplements the annotation rules to solve the problem of redundant interfaces and test cases being difficult to discover and causing maintenance chaos in existing technologies. When the matching result indicates that the interface exists in the interface library but is missing from the documentation, the system will annotate the interface and its corresponding call test cases, clearly marking redundant or invalid interface resources. This allows testers to quickly identify interfaces and test cases that do not need to be retained, avoiding redundant resources occupying storage and maintenance effort, and solving the problems of difficult interface and test case cleanup and cumbersome maintenance in traditional tools.

[0174] In some embodiments, the device may further include: The annotation selection receiving module receives user selection input based on annotations. The selection input includes deleting the annotation interface and the corresponding use case, or keeping the annotation interface and the corresponding use case. The annotation interface processing module is used to execute the deletion or retention of annotation interfaces and their corresponding use cases in response to selected input.

[0175] This application's embodiment, based on the labeled redundant interface, adds a user-selectable deletion or retention mechanism, balancing the needs of automated management with flexible manual control. By receiving user input based on labeled selections and responding to execute deletion or retention operations, the risk of accidental deletion that may occur during automatic system cleanup is reduced.

[0176] In some embodiments, the device may further include: The combination selection receiving module is used to receive a third input from the user, which includes combination selection information for multiple interfaces; The test case combination module is used to combine test cases corresponding to multiple interfaces in response to a third input to obtain test cases; The test case testing module is used to test test cases and obtain test results.

[0177] This application embodiment receives user input for a combination of multiple interfaces, integrates the test cases corresponding to these interfaces into a complete test case, and then executes the test to obtain the results. This combined test case construction method eliminates the need for testers to write complex test cases from scratch, improving test case construction efficiency; at the same time, it allows for flexible combination of different interfaces according to project needs, adapting to diverse business scenario testing requirements.

[0178] In some embodiments, the device may further include: The test case execution module is used to execute test cases; The variable extraction module is used to extract step-level variables, test-case-level variables, and environment-level variables during the execution process. The dynamic variable replacement module is used to dynamically replace step-level variables, test case-level variables, and environment-level variables to obtain test results.

[0179] This application refines the execution flow of combined test cases and introduces a dynamic variable replacement mechanism, solving the problems of low flexibility and repeated modifications required to adapt to different scenarios in traditional test cases. When executing test cases, three types of variables—step-level, test case-level, and environment-level—are extracted and dynamically replaced, allowing test cases to adapt to different test scenarios and environments.

[0180] Figure 9 A schematic diagram of the hardware structure of the terminal device provided in an embodiment of this application is shown.

[0181] The terminal device may include a processor 801 and a memory 802 storing computer program instructions.

[0182] Specifically, the processor 801 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0183] Memory 802 may include mass storage for data or instructions. For example, and not limitingly, memory 802 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. In one instance, memory 802 may include removable or non-removable (or fixed) media, or memory 802 may be non-volatile solid-state memory. Memory 802 may be internal or external to the integrated gateway disaster recovery device.

[0184] In one instance, memory 802 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the interface testing method according to this disclosure.

[0185] The processor 801 reads and executes computer program instructions stored in the memory 802 to achieve... Figure 1 The interface testing method in the illustrated embodiment.

[0186] In one example, the terminal device may also include a communication interface 803 and a bus 804. Wherein, for example... Figure 8 As shown, the processor 801, memory 802, and communication interface 803 are connected through bus 804 and complete communication with each other.

[0187] The communication interface 803 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0188] Bus 804 includes hardware, software, or both, that couples components of an end device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 804 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0189] Furthermore, in conjunction with the interface testing methods in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the interface testing methods in the above embodiments.

[0190] This application also provides a computer program product, including a computer program, which, when executed, implements any of the interface testing methods described in the above embodiments.

[0191] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0192] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or text segments used to perform the required tasks. Programs or text segments can be stored on machine-readable media or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable media" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, read-only memory (ROM), flash memory, erasable read-only memory (EROM), floppy disks, compact disc read-only memory (CD-ROM), optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Text segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0193] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0194] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0195] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method of interface testing, characterized by, The method comprises the following steps: In the interface test process, when a uniform resource locator (URL) of an interface document input by a user on an interface is received, an interface document is generated based on the URL, and the interface document comprises request addresses of all interfaces of a system; The request addresses of all interfaces of the system are matched with the request addresses of the interfaces stored in the interface library respectively to obtain a matching result; Based on the matching result, the interfaces in the interface list and the use cases corresponding to the interfaces are updated, and the interfaces and the use cases corresponding to the interfaces are marked; Information of the interfaces in the interface list and the use cases corresponding to the interfaces is displayed on a target interface.

2. The method of interface testing of claim 1, wherein, Based on the matching result, the interfaces in the interface list and the use cases corresponding to the interfaces are updated, and the interfaces and the use cases corresponding to the interfaces are marked, comprising: When the matching result indicates that the interface library does not comprise the request address of the interface, an interface template is generated, the interface is added in the interface list, and interface annotations of the interface are added.

3. The method of interface testing of claim 2, wherein, After the interface template is generated, the method further comprises: Receiving a first input of a user selecting debugging, wherein the first input comprises information of remote debugging or local debugging; Receiving a second input of the user, wherein the second input comprises verification parameters and submission parameters; the verification parameters are parameters input by the user based on the displayed interface template, and the submission parameters are parameters input by the user based on debugging requirement information; Based on the verification parameters and the submission parameters, the interface is checked to complete debugging of the interface.

4. The method of interface testing of claim 3, wherein, The checking of the interface based on the verification parameters and the submission parameters comprises: Reading all field names of a predicted response parameter, wherein the predicted response parameter comprises the verification parameters and the submission parameters; When the field name is a multi-level field, a field position mapping table is generated; Based on the field position mapping table, values of positions corresponding to the predicted response parameter and an actual response parameter are obtained respectively; the values are used to represent checking of field types and / or values.

5. The method of interface testing of claim 1, wherein, Based on the matching result, the interfaces in the interface list and the use cases corresponding to the interfaces are updated, and the interfaces and the use cases corresponding to the interfaces are marked, comprising: When the matching result indicates that the interface library comprises the request address of the interface, and the request method of the interface is changed, or the request parameters are changed, or the group field or structure of the response result is changed, the request method, the request parameters, the group field or structure field of the response result are marked in the interface list, and the use cases corresponding to the interfaces are marked.

6. The method of interface testing of claim 1, wherein, Based on the matching result, the interfaces in the interface list and the use cases corresponding to the interfaces are updated, and the interfaces and the use cases corresponding to the interfaces are marked, comprising: When the matching result indicates that the interface library does not comprise the interface in the interface document, the interface is marked in the interface list, and the interface calling use case is marked.

7. The method of interface testing of claim 6, wherein, After the information of the interfaces in the interface list and the use cases corresponding to the interfaces is displayed on the target interface, the method further comprises: Receiving a selection input of the user based on the marking, wherein the selection input comprises deleting the marked interface and the use cases corresponding to the interface, or retaining the marked interface and the use cases corresponding to the interface; In response to the selection input, the marked interface and the use cases corresponding to the interface are deleted or retained.

8. The method of interfacing testing according to any one of claims 4 to 7, characterized in that, The method further comprises: receiving a third input of a user, the third input comprising combination selection information of a plurality of interfaces; in response to the third input, combining use cases corresponding to the plurality of interfaces to obtain a test case; testing the test case to obtain a test result.

9. The method of interface testing of claim 8, wherein, The testing the test case to obtain a test result comprises: executing the test case; extracting step-level variables, use case-level variables and environment-level variables in the execution process; performing dynamic replacement on the step-level variables, the use case-level variables and the environment-level variables to obtain the test result.

10. An interface testing device, characterized by The device comprises: a receiving module configured to, in an interface testing process, acquire an interface document generated based on a uniform resource locator (URL) of an interface document input by a user on an interface interface when the URL of the interface document is received, the interface document comprising request addresses of all interfaces of a system; a matching module configured to match the request addresses of all interfaces of the system with request addresses of interfaces stored in an interface library respectively to obtain a matching result; a labeling module configured to update interfaces in an interface list and use cases corresponding to the interfaces based on the matching result, and label the interfaces and the use cases corresponding to the interfaces; a display module configured to display information of the interfaces in the interface list and the use cases corresponding to the interfaces on a target interface.

11. A terminal device, comprising: The device comprises a processor and a memory having computer program instructions stored thereon; The processor executes the computer program instructions to implement the interface testing method according to any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer readable storage medium has computer program instructions stored thereon, and the computer program instructions are executed by a processor to implement the interface testing method according to any one of claims 1-9.

13. A computer program product, characterised in that, The instructions in the computer program product are executed by a processor of an electronic device to cause the electronic device to perform the interface testing method according to any one of claims 1-9.

Images