Interface automatic test management method and device, equipment and medium
By using automated interface testing management methods, interface documents are automatically parsed and standardized test case data is generated. Combined with parameterized requests and grouping strategies, the problem of low efficiency due to repetitive operations in traditional interface testing is solved, achieving efficient, accurate, and intelligent management of interface testing, and improving test coverage and problem response speed.
Patent Information
- Application Number
- CN202511103167.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-07
- Publication Date
- 2025-11-25
AI Technical Summary
Traditional interface testing suffers from low efficiency and error-proneness due to repetitive operations, especially during regression verification and abnormal scenario reproduction. Manual operations are heavily relied upon, and the testing process requires frequent switching of test scenarios, maintenance of test data, and recording and updating of problem status, which can easily lead to omissions or incomplete test results.
An automated interface test management approach is adopted, which generates standardized interface test case data by parsing interface documents. Combined with parameterized request configuration and test case execution grouping strategies, the interface documents are automatically parsed, key fields are identified and project tags are generated, a parameter dependency graph is constructed, and semantic similarity and graph neural networks are used for grouping optimization. Multi-level verification rules and exception handling mechanisms are set up to achieve integrated management from test data generation to issue tracking.
It improves the efficiency and accuracy of interface testing, reduces inconsistencies and misoperations caused by human intervention, achieves a high degree of automation and intelligence in the interface testing process, significantly improves test coverage and problem response speed, and reduces the risk of human error.
Smart Images

Figure CN121009012A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of interface testing, and in particular to an interface automatic testing management method, device, equipment and medium. BACKGROUND
[0002] At present, interface testing, as an important part of system function testing, is mainly used to verify whether the data interaction between modules of a system conforms to the expected specification. The traditional interface testing process usually includes the following links: a tester designs test cases according to a product requirement document, executes the test cases and records the problems found, and then tracks and verifies the problems in a problem management system. The existing testing methods can either adopt manual testing or use interface testing tools for case design and execution. After testing is completed, the tester usually manually enters the problems found during execution into the problem management system for subsequent tracking and analysis.
[0003] However, in actual testing, the tester often needs to repeatedly test the same interface multiple times, such as regression verification and abnormal scenario reproduction, and such repetitive work still relies on manual operation in most tools. In addition, the tester needs to frequently switch test scenarios, maintain test data, and record and update problem status, which not only consumes time but also easily leads to missing of test results or incomplete problem records due to human negligence. SUMMARY
[0004] In order to solve the problems of low efficiency and easy errors in repetitive operations during testing, the present application provides an interface automatic testing management method, device, equipment and medium.
[0005] An interface automatic testing management method, the method comprising: Based on interface testing requirements, an interface document of an interface to be tested is obtained, the interface document is parsed, and interface case data containing interface case primary configuration content is generated, the interface case primary configuration content at least including interface path, request parameter and interface grouping information; Based on the interface case data, multiple request contents are configured for each interface case, the multiple request contents are based on the request parameter, and different request parameter values are set by parameterization to construct an input parameter value set for multi-scenario coverage; The interface case configured with the input parameter value set is executed in groups, a case execution group is generated based on the interface grouping information and a preset testing execution strategy, an execution order and an exception handling rule are set for the case execution group, and a corresponding execution link is generated; invoke the execution link based on the trigger request to sequentially use each group of the input parameter value set to request content to execute the interface use case in the use case execution group, and receive an interface response result returned by each interface use case, and automatically verify the interface response result based on a preset verification rule to generate a corresponding use case execution result; When the use case execution result fails, according to the exception handling rule, it is judged whether the current execution exception appearing in the use case execution result exists in a problem record in a problem management system, if it exists in the problem record in the problem management system and the current state of the problem record is a repaired state, the state of the problem record is updated to a corrected state, if it does not exist in the problem record in the problem management system, a new problem record is automatically submitted by calling a problem management interface; When all the interface use cases in the use case execution group are completed, the input parameter value set, the use case execution result and the problem record generated in the execution process are integrated to generate corresponding test execution data.
[0006] By using the above technical solution, the interface document is automatically parsed and the standardized interface use case data is generated, combined with the parameterized request configuration and the use case execution grouping strategy, a complete set of processes from test data generation, interface verification to problem tracking can be systematically completed, the efficiency and accuracy of interface testing are improved, and the inconsistency and misoperation caused by manual participation are significantly reduced.
[0007] Preferably, in the step of parsing the interface document to generate the interface use case data containing the interface use case primary configuration content, the step comprises: parsing the interface document based on a natural language processing model to identify the corresponding interface description content; extracting the interface use case primary configuration content in the interface description content, the interface use case primary configuration content comprising an interface path, a request parameter and interface grouping information, the interface grouping information being used to generate a corresponding use case execution group; automatically generating a project name and a use case group label to which the to-be-tested interface belongs based on the interface use case primary configuration content and in combination with context semantics; constructing corresponding interface use case data according to the interface path, the request parameter, the project name and the use case group label.
[0008] By using the above technical solution, the natural language processing technology is introduced to intelligently parse the interface document, not only the automatic extraction of the interface path, the request parameter, the grouping information and other key fields is realized, but also the project label and the use case label are generated in combination with context understanding, the structured expression and traceability of the interface use case data are enhanced, and the intelligent level of test scenario generation is improved.
[0009] Preferably, in the step of extracting the interface use case primary configuration content in the interface description content, the step comprises: When the project name and / or interface grouping information are not displayed in the interface description content, based on the extracted interface path and request parameter, similarity analysis is performed on the interface use case by a clustering algorithm to generate a corresponding similarity analysis result; According to the similarity analysis result, the interface use cases are logically classified to automatically generate the corresponding project name and interface grouping information of the interface use cases, which are used to complete the interface use case primary configuration content.
[0010] By using the above technical solution, when the project information or use case grouping is not explicitly marked in the interface description, the existing interface metadata is analyzed by means of the similarity clustering algorithm, the potential logical relationship between the interfaces can be automatically identified, and the project attribution and grouping information are completed accordingly, thereby ensuring the integrity of the interface use case data and the accuracy of the execution logic.
[0011] Preferably, in the step of constructing the corresponding interface use case data according to the interface path, the request parameter, the project name and the use case group label, the step comprises: Parsing the variable reference information in the request parameter and the preset parameter template to identify the parameter dependency relationship between the interface use cases; According to the parameter dependency relationship, a parameter dependency graph is constructed between the interface use cases, and the parameter dependency graph is determined as part of the interface use case data for saving.
[0012] By using the above technical solution, when constructing the interface use case data, the parameter dependency relationship between the interfaces is further mined, and the relationship is structured expressed by constructing the parameter dependency graph, which helps to identify the pre-post relationship between the requests during subsequent use case execution, improves the rationality of the execution sequence and optimizes the data transmission link between the use cases.
[0013] Preferably, in the step of performing grouping on the interface use cases configured with the input parameter value set, generating a use case execution group based on the interface grouping information and a preset test execution strategy, the step comprises: Based on the interface use case data, the semantic similarity between the project name of the interface to be tested and the historical project name is calculated, if the semantic similarity exceeds a preset similarity threshold, the interface use case is associated to the corresponding historical project, if the semantic similarity does not exceed the preset similarity threshold, the historical project template is reconfigured based on the preset historical project template; Based on the parameter dependency graph, a semantic graph structure between the interface use cases is constructed, and the nodes in the semantic graph structure are clustered based on a graph neural network to generate initial grouping information. Based on the preset use case execution optimization goal, the initial grouping information is iteratively adjusted through a reinforcement learning strategy to generate use case execution groups that meet the use case execution optimization goal.
[0014] By adopting the above technical solution, combined with semantic similarity assessment and graph neural network clustering technology, it can intelligently determine whether an interface belongs to an existing project and automatically generate a draft of test case grouping. Then, through reinforcement learning strategy, the group structure is continuously optimized in multiple rounds of training to ensure that the interface test case grouping has good cohesion and low coupling, which helps to improve the coverage and efficiency of batch execution.
[0015] Preferably, the step of automatically validating the interface response result based on preset verification rules to generate the corresponding test case execution result includes: Perform basic verification on the interface response result. The basic verification includes range matching verification of the status code in the interface response result and performance verification of the response time threshold in the interface response result, and generate the corresponding basic verification result. Perform field-level validation on the field values in the interface response results and generate the corresponding field-level validation results; When the field-level validation cannot cover the preset validation requirements, a complex validation is performed on the field value to generate the corresponding complex validation result. The basic verification results, the field-level verification results, and the complex verification results are integrated to generate the corresponding test case execution results.
[0016] By adopting the above technical solutions and setting up a multi-level response verification mechanism, including basic status code and response latency verification, field-level key value matching, and advanced rule verification under complex business logic, the correctness and robustness of the interface response can be comprehensively evaluated, ensuring that the test case execution results have high reliability and business fit.
[0017] Preferably, the exception handling rules include: When a request parameter is missing during the execution of the interface test case, the preset default parameter value is called to fill the input parameter value set, or the execution of the current interface test case is terminated and the corresponding exception information is generated; When the interface response result fails the preset verification rules, the current interface test case execution is terminated immediately according to the set execution mode, or the current exception is recorded and the subsequent interface test cases in the test case execution group are continued to be executed. When a network exception occurs during the execution of an interface test case, the interface request is automatically re-initiated based on a preset retry mechanism. If the retry fails after a preset number of times, the debugging process is triggered, and the current execution is paused to allow external modification of the input parameter value set or to skip the verification of the current interface test case. When other interfaces that an interface test case depends on have not yet completed configuration or return an exception, the preset simulated response generation rules are invoked to generate a dynamic simulated response based on the request parameters or to generate a matching simulated response result based on conditions, so as to replace the real response in the current interface test case's verification process.
[0018] By adopting the above technical solutions, the anomaly handling mechanism automatically identifies and responds to common problems such as missing parameters, response failures, network interruptions, and dependent interface anomalies. It covers processing paths such as parameter completion, execution mode switching, automatic retry and pause debugging, and simulated response compensation, thereby enhancing the system's self-healing ability and continuous testing capability in the face of abnormal scenarios and effectively improving the stability and robustness of the testing process.
[0019] The second objective of this invention is achieved through the following technical solution: An automated interface testing management device, characterized in that the automated interface testing management device comprises: The parsing module is used to obtain the interface document of the interface to be tested based on the interface testing requirements, parse the interface document, and generate interface test case data containing the initial configuration content of the interface test cases. The initial configuration content of the interface test cases includes at least the interface path, request parameters, and interface grouping information. The configuration module is used to configure multiple request contents for each interface use case based on the interface use case data. The multiple request contents are set with different request parameter values in a parameterized manner based on the request parameters, so as to construct an input parameter value set for multi-scenario coverage. The generation module is used to group the interface test cases configured with the input parameter value set into execution groups, generate test case execution groups based on the interface grouping information and the preset test execution strategy, set the execution order and exception handling rules for the test case execution groups, and generate corresponding execution links. The execution module is used to call the execution link based on the trigger request, so as to execute the interface test cases in the test case execution group in sequence using the request content of each group in the input parameter value set, and receive the interface response results returned by each interface test case, and automatically verify the interface response results based on the preset verification rules to generate the corresponding test case execution results; The submission module is used to determine whether the current execution exception in the test case execution result exists in the problem management system record according to the exception handling rules when the test case execution result fails. If it exists in the problem management system record and the current status of the problem record is "resolved", the status of the problem record is updated to "corrected". If it does not exist in the problem management system record, the problem management interface is called to automatically submit a new problem record. The integration module is used to integrate the set of input parameter values, test case execution results and problem records generated by the test case execution group during the execution process after all interface test cases in the test case execution group have been executed, and generate corresponding test execution data.
[0020] The above-mentioned objective three of this application is achieved through the following technical solution: A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the aforementioned interface automated test management method.
[0021] The fourth objective of this application is achieved through the following technical solution: A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the aforementioned interface automated test management method.
[0022] In summary, this application includes at least one of the following beneficial technical effects: This application introduces an interface document parsing method based on structured parsing and natural language processing technologies. Combined with parameterized request configuration, a mechanism for constructing input parameter sets for multiple request data sets, an automated test case execution chain generation mechanism, a multi-level validation rule system for test case execution results, and automatic integration logic with the issue management system, it achieves integrated automated management of test case generation, execution, validation, issue recording, and backtracking in the interface testing process. This avoids the time-consuming and error-prone operations of manually maintaining test cases, manually submitting issue records, and repeatedly executing test cases in traditional testing. By setting execution strategies and exception handling rules, it can dynamically judge execution results during testing, automatically identify issues and submit records, and generate archived data based on the completeness of test case execution, improving overall testing efficiency and accuracy. It achieves a high degree of automation and intelligence throughout the entire interface testing process, significantly reducing manual intervention, improving test coverage and issue response speed, thereby effectively improving the work efficiency of testers and reducing the risk of human error. Attached Figure Description
[0023] Figure 1 This is a flowchart of an interface automated test management method according to an embodiment of this application. Detailed Implementation
[0024] The present application will be further described in detail below with reference to the accompanying drawings.
[0025] In one embodiment, such as Figure 1 As shown, this application discloses an interface automated test management method, which includes: S10. Based on the interface testing requirements, obtain the interface documentation for the interface to be tested, parse the interface documentation, and generate interface test case data containing the initial configuration content of the interface test cases. The initial configuration content of the interface test cases includes at least the interface path, request parameters, and interface grouping information. Interface testing requirements refer to the verification goals and boundaries proposed by testers for a specific system or module under test, based on business objectives or development documentation. For example, which interfaces need to be verified, which business scenarios need to be covered, and what the expected verification logic is. Interface documentation is technical information describing the definition, structure, and behavior of each interface. It typically includes the interface path, request method, parameter description, response structure, and status code meaning, and is the main source for generating interface test case data. The initial configuration content of the interface test cases is the basic information that must be clearly defined when constructing test cases. It mainly includes the interface path (Uniform Resource Identifier for interface access), request parameters (data fields to be passed during interface calls), and interface grouping information (label information used to logically categorize interfaces). Interface test case data is a collection of information extracted and structured from the interface documentation, used to generate various stages of the subsequent test process.
[0026] S20. Based on the interface test case data, configure multiple request contents for each interface test case. The multiple request contents are based on the request parameters and set different request parameter values in a parameterized manner to construct an input parameter value set for multi-scenario coverage. The request content is a set of specific request data instances defined under an interface test case. The input parameter value set is a collection of parameter combinations defined in all request contents for multi-scenario testing. It is the core input data in the test execution process.
[0027] S30. For interface test cases configured with input parameter value sets, execution grouping is performed. Based on interface grouping information and preset test execution strategies, test case execution groups are generated, and execution order and exception handling rules are set for each test case execution group. Simultaneously, corresponding execution links are generated. Execution grouping is the process of dividing interface test cases into several groups based on the logic or configuration between test cases; each group is called a test case execution group. Interface grouping information serves as one of the grouping references, used to categorize functionally related or structurally similar interfaces. The test execution strategy is a set of preset decision logics used by the system to guide how to group, sort, concurrently, or serially execute interfaces, such as prioritizing the execution of core interfaces and placing interfaces with close dependencies in the same group. A test case execution group is a concretely constructed test task unit; the execution order refers to the order in which interface test cases within each test case execution group are scheduled for execution in the test process. Exception handling rules are automatic response plans configured for possible errors or exceptions during interface test case execution, including behavioral logic such as retry, skip, termination, and logging. An execution link is the call entry point used to trigger the execution of interface test cases; it can be a link address or call command generated internally by the system.
[0028] S40. Based on the trigger request, the execution link is invoked to sequentially execute the interface test cases in the test case execution group using each group of request content from the input parameter value set. The interface response results returned by each interface test case are received, and the interface response results are automatically verified based on preset validation rules to generate the corresponding test case execution results. The interface response result refers to the returned data or status received after executing the interface call, and is the direct basis for verifying the correctness of the interface behavior. Validation rules are the checking logic set for the response content, including but not limited to status codes, field values, response time, and business logic verification. The test case execution result is the judgment output after interface execution, used to indicate whether a certain test scenario has passed. Execution exceptions refer to specific problems that occur during execution that cause test case execution failure, such as incorrect parameters, network interruption, or abnormal return values.
[0029] S50. When a test case execution fails, according to the exception handling rules, determine whether the current execution exception in the test case execution result exists in the problem management system's problem record. If it exists in the problem management system and its current status is "resolved," update the problem record's status to "corrected." If it does not exist in the problem management system, automatically submit a new problem record by calling the problem management interface. The problem management system is an enterprise system platform used to centrally record, track, allocate, and resolve software defects or testing issues. A problem record is a single problem entity generated in the problem management system, recording information such as the problem's description, status, and responsible party. The problem management interface is a data channel used for automatic communication between the interface testing system and the problem management system.
[0030] S60. After all interface test cases in the test case execution group have been executed, the input parameter value set, test case execution results, and problem records generated during the execution process are integrated to generate corresponding test execution data. Test execution data is the final output of the entire interface testing process, including summary information on inputs, responses, and exceptions during the testing process, used for test reports or subsequent analysis.
[0031] For example, in an e-commerce system, testers want to verify the accuracy and stability of a product search interface. Their interface test requirement is to "verify whether searching for products based on keywords returns the correct data." The testing system extracts the interface path " / api / search / items" from the corresponding interface documentation. The request parameters include "keyword" and "page." The initial configuration of the interface test case also includes grouping the interface into the "Product Services" group. The system configures three request contents for this interface test case, testing scenarios with keywords "mobile phone," "television," and "refrigerator," respectively. These three sets of parameters are grouped into the input parameter value set. Based on the interface grouping information and the default serial test execution strategy, this test case is grouped into a separate test case execution group and an execution link is generated. When the execution link is called, the system executes the three sets of parameters sequentially and returns the response results. During one execution, a status code of 500 is returned, triggering the exception handling rules. The system recognizes that this issue is not recorded in the issue management system and automatically submits a new issue record through the issue management interface. After all requests are executed, the system integrates the parameters, responses, and issue information during the test case execution process to generate the test execution data for this product search interface.
[0032] Furthermore, the step of parsing the interface documentation to generate interface test case data containing the initial configuration content of the interface test cases includes: S101. Based on a natural language processing model, the interface document is parsed to identify the corresponding interface description content; S102. Extract the primary configuration content of the interface test cases from the interface description. The primary configuration content of the interface test cases includes the interface path, request parameters and interface grouping information. The interface grouping information is used to generate the corresponding test case execution group. S103. Based on the initial configuration content of the interface test cases and combined with the context semantics, automatically generate the project name and test case group label of the interface to be tested; S104. Construct the corresponding interface test case data based on the interface path, request parameters, project name, and test case group label.
[0033] In this embodiment, during the specific implementation process, the system first receives the interface document uploaded based on testing requirements. For example, for the product search interface in an e-commerce platform, the path described in the interface document is " / api / search / items", the request method is GET, and the request parameters include the keyword "keyword" and the pagination parameter "page". The system parses the main text of the interface document by calling a preset natural language processing model, automatically identifies the description paragraphs of the interface, and extracts the path information, request method, request parameters, and their descriptions. After extracting the above key content, the system further analyzes whether the interface document clearly marks the project and interface group information. If no marking is displayed, based on the significant keywords in the interface path and request parameters, the system identifies the similarity features between the interface and historical interface use cases through semantic vector modeling and clustering algorithms, automatically classifies the interface into the "Product Services" group, and identifies its high semantic similarity with the existing "Product Module" project in the e-commerce project. Therefore, the system automatically labels the project to which the interface belongs as "Product Services System" and generates a "High-Frequency Query" use case group label. After extracting the interface path and request parameters, the system constructs the basic configuration data structure for the corresponding interface test cases, completing the initial annotation of the interface path, parameter list, project, and test case group. This provides structured data support for subsequent test case generation, input parameter setting, and test execution. Through this process, users can achieve automatic categorization, project association, and tag generation without manually annotating interface classification information, thereby improving the efficiency and consistency of the interface test preparation phase.
[0034] Furthermore, the step of extracting the initial configuration content of the interface use cases from the interface description includes: S1021. When the project name and / or interface grouping information are not displayed in the interface description, a clustering algorithm is used to perform similarity analysis on the interface use cases based on the extracted interface path and request parameters, and the corresponding similarity analysis results are generated. S1022. Based on the similarity analysis results, the interface test cases are logically categorized to automatically generate the project name and interface grouping information corresponding to the interface test cases, which are then used to complete the initial configuration content of the interface test cases.
[0035] In this embodiment, when the interface documentation does not explicitly indicate the project name and / or interface group information to which the interface belongs, the system first automatically extracts basic configuration content such as the interface path and request parameters based on a natural language processing model, and uses this information to perform structured coding of the interface use cases. Based on this, the system introduces clustering algorithms, such as K-means or hierarchical clustering, to perform similarity analysis on the extracted multiple interface use cases, mainly evaluating their similarity in request path structure, parameter naming conventions, and functional semantics. Through this clustering process, the system can automatically divide the interface use cases into several logically highly related groups, each group representing a potential interface group or business module. Furthermore, the system performs semantic similarity matching between the feature vectors of each use case group and historically archived project templates, and calculates similarity values using semantic models such as Sentence-BERT. If the similarity between a test case group and a historical project name exceeds a preset threshold, the test case group is automatically associated with that historical project and used as its project name. If no match is found, the system automatically generates a new project tag based on the test case group's structural characteristics, parameter patterns, and interface level, and simultaneously generates the project's initial configuration, including request prefixes and default environment information, to intelligently complete the project name and interface group information for the interface test cases. This completion result is synchronously updated in the interface test case data, ensuring that subsequent test case execution grouping and execution strategy formulation have complete contextual information and maintain the closed loop of project affiliation logic. This solution significantly reduces the workload of manually maintaining interface groups and project identifiers and effectively improves the intelligence level and execution accuracy of interface management.
[0036] Furthermore, the step of constructing the corresponding interface test case data based on the interface path, request parameters, project name, and test case group tags includes: S1041. Parse the variable reference information in the request parameters and preset parameter templates to identify the parameter dependencies between interface test cases; S1042. Based on the parameter dependency relationship, construct a parameter dependency graph between interface use cases, and save the parameter dependency graph as part of the interface use case data.
[0037] In this embodiment, the system further structures the request parameter fields based on the interface path, request parameters, project name, and use case group tags parsed from the interface document, and identifies the variable reference relationships involved. For example, there are dynamic variables defined in the form of "{{token}}" in the request parameters. Based on a preset parameter template and combined with the semantic information parsed by the natural language processing model, the system automatically identifies the source and dependency relationships of these variables, and forms a preliminary dependency structure by constructing a reference graph between parameters. On this basis, a parameter dependency graph between interface use cases is further generated. The nodes of this graph represent specific interface use cases or parameter fields, and the edges represent reference relationships or transmission paths. The graph generation process not only considers the direct matching of parameter names, but also integrates contextual semantic similarity, interface path structure, and parameter transmission patterns recorded in historical execution data. If the project affiliation or interface grouping information is not explicitly marked in the interface documentation, the system can utilize the established dependency graph as a semantic foundation. Through clustering algorithms (such as K-means), interfaces that are structurally and semantically highly related are automatically grouped into the same logical group. Existing project tags are matched, or suggestions for new project affiliations are provided to complete the basic configuration content of the interface test cases. The resulting parameter dependency graph not only serves as the basis for test orchestration logic analysis but is also stored in a structured manner by the system as an important component of the interface test case data. This data is used for subsequent optimization of execution grouping strategies and construction of execution chains, thereby improving the intelligence and coverage efficiency of the testing process.
[0038] Furthermore, the step of grouping interface test cases configured with input parameter value sets into execution groups, and generating test case execution groups based on interface grouping information and preset test execution strategies, includes: S301. Based on the interface test case data, calculate the semantic similarity between the project name of the interface to be tested and the historical project name. If the semantic similarity exceeds the preset similarity threshold, associate the interface test case with the corresponding historical project. If the semantic similarity does not exceed the preset similarity threshold, reconfigure based on the preset historical project template. S302. Based on the parameter dependency graph, construct a semantic graph structure between interface use cases, and perform clustering processing on the nodes in the semantic graph structure based on graph neural network to generate initial grouping information; S303. Based on the preset use case execution optimization goal, the initial grouping information is iteratively adjusted through reinforcement learning strategy to generate use case execution groups that meet the use case execution optimization goal.
[0039] In this embodiment, to achieve effective execution grouping of interface test cases, the semantic similarity between the project name of the current test interface and the existing historical project names in the system is calculated first, based on the interface test case data obtained from parsing the interface documentation, by calling the semantic analysis module. This semantic similarity calculation uses a pre-trained Sentence-BERT model, combining interface path, interface grouping information, and input parameter value sets for representation matching. When the similarity result exceeds a set threshold (e.g., 0.8), the interface test case is automatically associated with the most similar historical project, inheriting the default request address and environment parameter configuration under that project. If the matching fails, a new project configuration is automatically generated for the interface test case based on a historical project template (e.g., microservice architecture, monolithic application structure). Subsequently, the system performs graph structure modeling on the parameter dependencies between all interface test cases, generating a semantic graph structure. Nodes in the graph represent different interface test cases, and edges represent parameter reference relationships or call order dependencies between them. The semantic graph is further clustered using a graph neural network (GNN) model to generate initial test case grouping information, resulting in strong coupling between the structure and parameters of the interface test cases within each group. To optimize testing efficiency and coverage, the system also introduces a reinforcement learning mechanism. Using the shortest execution time and the widest functional path coverage as optimization goals, it iteratively adjusts the strategy based on the initial test case grouping, dynamically adjusting the grouping boundaries and execution order of interface test cases. Ultimately, it generates test case execution groups that meet the set goals, providing a more efficient structural foundation for subsequent concurrent execution, exception management, and result tracking. This implementation not only improves the intelligence and rationality of grouping but also significantly reduces repetitive work for testers in project configuration and dependency judgment.
[0040] Furthermore, the step of automatically validating the interface response results based on preset validation rules to generate the corresponding test case execution results includes: S401. Perform basic verification on the interface response result. The basic verification includes range matching verification of the status code in the interface response result and performance verification of the response time threshold in the interface response result, and generate the corresponding basic verification result. S402. Perform field-level validation on the field values in the interface response results and generate the corresponding field-level validation results. S403. When field-level validation cannot cover the preset validation requirements, perform complex validation on the field value and generate the corresponding complex validation result. S404 integrates basic validation results, field-level validation results, and complex validation results to generate corresponding test case execution results.
[0041] In this embodiment, the system first receives response data returned by each interface during the execution of interface test cases and automatically verifies the response results. Specifically, the system performs multi-level verification on each response according to preset verification rules to ensure that the interface behaves as expected under different sets of input parameter values. The verification process includes basic-level status code matching and response time performance evaluation. The system determines whether the interface returns status codes within the specified range and monitors whether the response latency meets the set performance threshold. After passing the basic verification, the system further enters the field-level verification process to verify whether the key field values in the returned data are consistent with the expected values. This stage can significantly improve test coverage, especially when the interface return structure contains complex nested fields or business identifiers. In some complex scenarios, field-level verification is difficult to meet the verification requirements of specific business logic. The system will call extended complex verification strategies to perform higher-level verification through expression judgment, field combination logic analysis, and even scripted verification methods. For example, it can be used to identify specific flag bits or rule fields that should be activated under certain conditions in the interface return value. Throughout the automated verification process, the system integrates basic verification results, field-level verification results, and complex verification results to generate structured test case execution result data, which is then written into the test execution data record for subsequent issue tracking and quality assessment analysis. This implementation method significantly reduces the workload of manual verification through a layered and progressive automated verification mechanism, improves the accuracy of interface testing and the real-time response to issue discovery, and is particularly suitable for high-frequency interface changes and regression testing tasks.
[0042] Furthermore, the exception handling rules include: When a request parameter is missing during the execution of an interface test case, the preset default parameter value is called to fill the input parameter value set, or the execution of the current interface test case is terminated and the corresponding exception information is generated. When the interface response fails to pass the preset verification rules, the current interface test case execution can be terminated immediately according to the set execution mode, or the current exception can be recorded and the subsequent interface test cases in the test case execution group can be continued to be executed. When a network exception occurs during the execution of an interface test case, the interface request is automatically re-initiated based on a preset retry mechanism. If the retry fails after a preset number of times, the debugging process is triggered, and the current execution is paused to allow external modification of the input parameter value set or to skip the validation of the current interface test case. When other interfaces that an interface test case depends on have not yet completed configuration or return an exception, the preset simulated response generation rules are invoked to generate a dynamic simulated response based on the request parameters or to generate a matching simulated response result based on conditions, so as to replace the real response in the current interface test case's verification process.
[0043] In this embodiment, the system pre-configures and invokes various exception handling strategies during the execution of interface test cases to ensure the stability and controllability of the testing process. When an interface test case fails to execute due to missing request parameters, the system first checks if a preset default value exists for that parameter. If it does, the system automatically fills the current input parameter value set with the default value and continues executing the interface test case. If no corresponding default value exists, the system will terminate the execution of the interface test case and record the exception information for subsequent analysis and localization. Simultaneously, to adapt to the fault tolerance requirements of different business processes, the system provides two execution modes: In strict mode, once the interface response result fails the validation rules, the execution of the interface test case is immediately terminated to prevent error propagation; in lenient mode, the system records the exception result but continues to execute subsequent test cases in the test case group to ensure the overall progress of the testing task. When network interruption, response timeout, or other exceptions occur during the interface request process, the system will automatically re-initiate the interface request according to the preset retry mechanism. If the retry count reaches a set threshold and still fails, the system will enter debug mode, suspend the execution of the current test case, and allow testers to manually modify parameters or skip the current validation to continue the testing process. To address situations where some API dependencies are not yet fully developed or where API return results are unstable, the system also supports a mock mechanism. This mechanism matches request parameters using simulated response rules to generate preset response content for verifying the process, ensuring the integrity of the testing process to a certain extent. Furthermore, if an anomaly in the current API test case is found to be associated with a record in the issue management system, and that record's status is "fixed," the system will automatically update the record's status to "corrected." Otherwise, it will call the interface connected to the third-party issue management system to submit a new issue record based on the current anomaly information, achieving automatic tracking and closed-loop management of issues during testing. Through these mechanisms, this implementation effectively improves the fault tolerance and intelligence level of the API testing process, reduces manual intervention by testers, and improves the efficiency and accuracy of regression verification.
[0044] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0045] In one embodiment, an interface automated testing management device is provided, which corresponds one-to-one with the interface automated testing management method described in the above embodiment. This interface automated testing management device includes a parsing module, a configuration module, a generation module, an execution module, a submission module, and an integration module. Detailed descriptions of each functional module are as follows: An automated interface testing management device, the automated interface testing management device comprising: The parsing module is used to obtain the interface document of the interface to be tested based on the interface testing requirements, parse the interface document, and generate interface test case data containing the initial configuration content of the interface test cases. The initial configuration content of the interface test cases includes at least the interface path, request parameters, and interface grouping information. The configuration module is used to configure multiple request contents for each interface use case based on the interface use case data. The multiple request contents are set with different request parameter values in a parameterized manner based on the request parameters, so as to construct an input parameter value set for multi-scenario coverage. The generation module is used to group the interface test cases configured with the input parameter value set into execution groups, generate test case execution groups based on the interface grouping information and the preset test execution strategy, set the execution order and exception handling rules for the test case execution groups, and generate corresponding execution links. The execution module is used to call the execution link based on the trigger request, so as to execute the interface test cases in the test case execution group in sequence using the request content of each group in the input parameter value set, and receive the interface response results returned by each interface test case, and automatically verify the interface response results based on the preset verification rules to generate the corresponding test case execution results; The submission module is used to determine whether the current execution exception in the test case execution result exists in the problem management system record according to the exception handling rules when the test case execution result fails. If it exists in the problem management system record and the current status of the problem record is "resolved", the status of the problem record is updated to "corrected". If it does not exist in the problem management system record, the problem management interface is called to automatically submit a new problem record. The integration module is used to integrate the set of input parameter values, test case execution results and problem records generated by the test case execution group during the execution process after all interface test cases in the test case execution group have been executed, and generate corresponding test execution data.
[0046] For specific limitations regarding an interface automated test management device, please refer to the limitations of an interface automated test management method described above, which will not be repeated here. Each module in the aforementioned interface automated test management device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each module.
[0047] In one embodiment, a computer device is provided, which may be a server. The computer device includes a processor, memory, a network interface, and a database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage medium. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements an automated interface testing and management method.
[0048] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: S10. Based on the interface testing requirements, obtain the interface document of the interface to be tested, parse the interface document, and generate interface test case data containing the initial configuration content of the interface test cases. The initial configuration content of the interface test cases shall at least include the interface path, request parameters, and interface grouping information. S20. Based on the interface use case data, configure multiple request contents for each interface use case. The multiple request contents are based on the request parameters and different request parameter values are set in a parameterized manner to construct an input parameter value set for multi-scenario coverage. S30. Perform execution grouping on interface test cases configured with input parameter value sets, generate test case execution groups based on interface grouping information and preset test execution strategies, set execution order and exception handling rules for test case execution groups, and generate corresponding execution links. S40. Based on the trigger request, call the execution link to execute the interface test cases in the test case execution group in sequence using the request content of each group in the input parameter value set, and receive the interface response results returned by each interface test case. Automatically verify the interface response results based on the preset verification rules to generate the corresponding test case execution results. S50. When the test case execution result fails, according to the exception handling rules, determine whether the current execution exception that appears in the test case execution result exists in the problem management system. If it exists in the problem management system and the current status of the problem record is "resolved", then update the status of the problem record to "corrected". If it does not exist in the problem management system, then call the problem management interface to automatically submit a new problem record. S60. After all interface test cases in the test case execution group have been executed, integrate the input parameter value set, test case execution results and problem records generated by the test case execution group during the execution process to generate the corresponding test execution data.
[0049] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: S10. Based on the interface testing requirements, obtain the interface document of the interface to be tested, parse the interface document, and generate interface test case data containing the initial configuration content of the interface test cases. The initial configuration content of the interface test cases shall at least include the interface path, request parameters, and interface grouping information. S20. Based on the interface use case data, configure multiple request contents for each interface use case. The multiple request contents are based on the request parameters and different request parameter values are set in a parameterized manner to construct an input parameter value set for multi-scenario coverage. S30. Perform execution grouping on interface test cases configured with input parameter value sets, generate test case execution groups based on interface grouping information and preset test execution strategies, set execution order and exception handling rules for test case execution groups, and generate corresponding execution links. S40. Based on the trigger request, call the execution link to execute the interface test cases in the test case execution group in sequence using the request content of each group in the input parameter value set, and receive the interface response results returned by each interface test case. Automatically verify the interface response results based on the preset verification rules to generate the corresponding test case execution results. S50. When the test case execution result fails, according to the exception handling rules, determine whether the current execution exception that appears in the test case execution result exists in the problem management system. If it exists in the problem management system and the current status of the problem record is "resolved", then update the status of the problem record to "corrected". If it does not exist in the problem management system, then call the problem management interface to automatically submit a new problem record. S60. After all interface test cases in the test case execution group have been executed, integrate the input parameter value set, test case execution results and problem records generated by the test case execution group during the execution process to generate the corresponding test execution data.
[0050] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.
[0051] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.
[0052] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.
Claims
1. A method for managing automated interface testing, characterized in that, The interface automated test management method includes: Based on the interface testing requirements, obtain the interface document of the interface to be tested, parse the interface document, and generate interface test case data containing the initial configuration content of the interface test cases. The initial configuration content of the interface test cases includes at least the interface path, request parameters, and interface grouping information. Based on the interface use case data, multiple request contents are configured for each interface use case. The multiple request contents are set with different request parameter values in a parameterized manner based on the request parameters, so as to construct an input parameter value set for multi-scenario coverage. The interface test cases configured with the input parameter value set are grouped for execution. Based on the interface grouping information and the preset test execution strategy, test case execution groups are generated, and the execution order and exception handling rules are set for the test case execution groups. At the same time, corresponding execution links are generated. The execution link is invoked based on the trigger request to execute the interface test cases in the test case execution group in sequence using the request content of each group in the input parameter value set, and the interface response results returned by each interface test case are received. The interface response results are automatically verified based on the preset verification rules to generate the corresponding test case execution results. When the test case execution result fails, according to the exception handling rules, it is determined whether the current execution exception that appears in the test case execution result exists in the problem management system. If it exists in the problem management system and the current status of the problem record is "resolved", the status of the problem record is updated to "corrected". If it does not exist in the problem management system, the problem management interface is called to automatically submit a new problem record. Once all interface test cases in the test case execution group have been executed, the input parameter value set, test case execution results, and problem records generated during the execution process are integrated to generate corresponding test execution data.
2. The interface automated test management method according to claim 1, characterized in that, The step of parsing the interface document to generate interface test case data containing the initial configuration content of the interface test cases includes: Based on a natural language processing model, the interface document is parsed to identify the corresponding interface description content; Extract the primary configuration content of the interface use cases from the interface description content. The primary configuration content of the interface use cases includes the interface path, request parameters, and interface grouping information. The interface grouping information is used to generate the corresponding use case execution group. Based on the initial configuration of the interface test case and combined with the context semantics, the project name and test case group tag of the interface to be tested are automatically generated. Based on the interface path, the request parameters, the project name, and the use case group label, construct the corresponding interface use case data.
3. The interface automated test management method according to claim 2, characterized in that, The step of extracting the primary configuration content of the interface use cases from the interface description content includes: When the project name and / or interface grouping information are not displayed in the interface description, a clustering algorithm is used to perform similarity analysis on the interface use cases based on the extracted interface path and request parameters, and corresponding similarity analysis results are generated. Based on the similarity analysis results, the interface use cases are logically categorized to automatically generate the project name and interface grouping information corresponding to the interface use cases, which are then used to complete the initial configuration content of the interface use cases.
4. The interface automated test management method according to claim 2, characterized in that, The step of constructing corresponding interface use case data based on the interface path, the request parameters, the project name, and the use case group tag includes: Parse the variable reference information in the request parameters and preset parameter templates to identify the parameter dependencies between the interface use cases; Based on the parameter dependencies, a parameter dependency graph is constructed between the interface use cases, and the parameter dependency graph is identified as part of the interface use case data and saved.
5. The interface automated test management method according to claim 4, characterized in that, The step of grouping interface test cases configured with the input parameter value set into execution groups, and generating test case execution groups based on the interface grouping information and the preset test execution strategy, includes: Based on the interface use case data, the semantic similarity between the project name of the interface to be tested and the historical project name is calculated. If the semantic similarity exceeds a preset similarity threshold, the interface use case is associated with the corresponding historical project. If the semantic similarity does not exceed the preset similarity threshold, the configuration is re-established based on the preset historical project template. Based on the parameter dependency graph, a semantic graph structure between the interface use cases is constructed, and the nodes in the semantic graph structure are clustered based on a graph neural network to generate initial grouping information; Based on the preset use case execution optimization goal, the initial grouping information is iteratively adjusted through a reinforcement learning strategy to generate use case execution groups that meet the use case execution optimization goal.
6. The interface automated test management method according to claim 1, characterized in that, The step of automatically validating the interface response result based on preset validation rules to generate the corresponding test case execution result includes: Perform basic verification on the interface response result. The basic verification includes range matching verification of the status code in the interface response result and performance verification of the response time threshold in the interface response result, and generate the corresponding basic verification result. Perform field-level validation on the field values in the interface response results and generate the corresponding field-level validation results; When the field-level validation cannot cover the preset validation requirements, a complex validation is performed on the field value to generate the corresponding complex validation result. The basic verification results, the field-level verification results, and the complex verification results are integrated to generate the corresponding test case execution results.
7. The interface automated test management method according to claim 1, characterized in that, The exception handling rules include: When a request parameter is missing during the execution of the interface test case, the preset default parameter value is called to fill the input parameter value set, or the execution of the current interface test case is terminated and the corresponding exception information is generated; When the interface response result fails the preset verification rules, the current interface test case execution is terminated immediately according to the set execution mode, or the current exception is recorded and the subsequent interface test cases in the test case execution group are continued to be executed. When a network exception occurs during the execution of an interface test case, the interface request is automatically re-initiated based on a preset retry mechanism. If the retry fails after a preset number of times, the debugging process is triggered, and the current execution is paused to allow external modification of the input parameter value set or to skip the verification of the current interface test case. When other interfaces that an interface test case depends on have not yet completed configuration or return an exception, the preset simulated response generation rules are invoked to generate a dynamic simulated response based on the request parameters or to generate a matching simulated response result based on conditions, so as to replace the real response in the current interface test case's verification process.
8. An interface automated testing management device, characterized in that, The interface automated test management device includes: The parsing module is used to obtain the interface document of the interface to be tested based on the interface testing requirements, parse the interface document, and generate interface test case data containing the initial configuration content of the interface test cases. The initial configuration content of the interface test cases includes at least the interface path, request parameters, and interface grouping information. The configuration module is used to configure multiple request contents for each interface use case based on the interface use case data. The multiple request contents are set with different request parameter values in a parameterized manner based on the request parameters, so as to construct an input parameter value set for multi-scenario coverage. The generation module is used to group the interface test cases configured with the input parameter value set into execution groups, generate test case execution groups based on the interface grouping information and the preset test execution strategy, set the execution order and exception handling rules for the test case execution groups, and generate corresponding execution links. The execution module is used to call the execution link based on the trigger request, so as to execute the interface test cases in the test case execution group in sequence using the request content of each group in the input parameter value set, and receive the interface response results returned by each interface test case, and automatically verify the interface response results based on the preset verification rules to generate the corresponding test case execution results; The submission module is used to determine whether the current execution exception in the test case execution result exists in the problem management system record according to the exception handling rules when the test case execution result fails. If it exists in the problem management system record and the current status of the problem record is "resolved", the status of the problem record is updated to "corrected". If it does not exist in the problem management system record, the problem management interface is called to automatically submit a new problem record. The integration module is used to integrate the set of input parameter values, test case execution results and problem records generated by the test case execution group during the execution process after all interface test cases in the test case execution group have been executed, and generate corresponding test execution data.
9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the interface automated test management method as described in any one of claims 1 to 6.
10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the interface automated test management method as described in any one of claims 1 to 6.
Citation Information
Cited By
Intelligent agent assisted test method and device, computer equipment and storage medium
CN121681395A
API (Application Program Interface) online debugging method and system based on semantic analysis
CN122152678A