Multi-agent test case generation method and device based on test intention graph

Abstract

This application discloses a multi-agent test case generation method and apparatus based on a test intent graph, relating to the fields of artificial intelligence and software testing. The method includes: acquiring multiple heterogeneous data sources; performing data standardization, entity alignment, and cross-validation on the heterogeneous data sources to obtain a fused perception result; constructing a test intent graph based on the fused perception result; for each node in the test intent graph, calling N test case agents to generate N candidate test case sets; having a review agent quantitatively score the N candidate test case sets and selecting a reference test case set based on the scoring results; validating each test case in the reference test case set, and automatically repairing test cases that fail verification until the repaired test cases pass verification. This application solves the technical problem of low generation efficiency caused by the lack of a systematic guiding framework in the test case generation process in existing technologies.

Description

Technical Field

[0001] This application relates to the fields of artificial intelligence and software testing, and more specifically, to a method and apparatus for generating multi-agent test cases based on test intent graphs. Background Technology

[0002] In the field of software testing, test case generation is a core part of the testing process. Traditional test case generation methods mainly rely on testers writing them manually, which suffers from problems such as low efficiency, strong subjectivity, and the tendency to miss test scenarios.

[0003] In recent years, some automated test case generation technologies have emerged, improving generation efficiency to some extent. However, these technologies still have the following shortcomings in practical applications:

[0004] The test case generation process lacks a systematic guiding framework, and the collaboration between various processing stages is relatively simple, typically employing a fixed processing order that is difficult to dynamically adjust based on the complexity and diversity of test requirements. When faced with different types of test requirements, a single processing model cannot flexibly adapt, leading to repeated adjustments to the test case generation process and low overall generation efficiency. Summary of the Invention

[0005] This application provides a method and apparatus for generating multi-agent test cases based on test intent graphs, which at least solves the technical problem of low generation efficiency caused by the lack of a systematic guiding framework in the test case generation process in the prior art.

[0006] According to one aspect of the embodiments of this application, a method for generating multi-agent test cases based on a test intent graph is provided, comprising: acquiring multiple heterogeneous data sources, wherein the multiple heterogeneous data sources include at least: requirement specifications, historical defect databases, and user behavior logs; performing data standardization, entity alignment, and cross-validation on the multiple heterogeneous data sources to obtain a fusion perception result, wherein the fusion perception result is used to characterize a unified knowledge representation formed after the fusion processing of the multiple heterogeneous data sources; and constructing a test intent graph based on the fusion perception result, wherein the test intent graph is a directed graph structure with test intents as nodes and the relationships between test intents as edges, used to represent... The hierarchical organization of test requirements is defined. For each node in the test intent graph, N test case agents are invoked to generate test case candidate sets, resulting in N test case candidate sets, where N is an integer greater than 1. Each test case agent generates one test case candidate set. The review agent quantitatively scores the N test case candidate sets from multiple dimensions and selects one test case candidate set as the reference test case set based on the scoring results. Each test case in the reference test case set is verified, and test cases that fail verification are automatically repaired until the repaired test cases pass verification. The verified test cases are then used as target test cases.

[0007] Optionally, data standardization, entity alignment, and cross-validation are performed on multiple heterogeneous data sources, including: converting the multiple heterogeneous data sources into a unified knowledge representation format to obtain multiple standardized data; identifying entities belonging to the same functional module from the multiple standardized data and establishing relationships between entities to obtain associated fused data; and performing cross-validation on the associated fused data. When the same risk point is detected to be pointed to by both the historical defect database and user behavior logs and is not described in the requirements specification, the priority of the risk point is increased to obtain the fused perception result.

[0008] Optionally, constructing a test intent graph based on the fusion perception results includes: extracting multiple candidate test intents from the fusion perception results to form a candidate test intent set; performing matching and attribute completion operations on the candidate test intents in the candidate test intent set based on an intent pattern library to obtain a target test intent set, wherein the matching operation is used to calculate the similarity between the candidate test intents and intent templates in the intent pattern library, and the attribute completion operation is used to supplement the missing attribute information of the candidate test intents based on the matched intent templates; obtaining a set of intent association relationships corresponding to the target test intent set, wherein the set of intent association relationships includes the dependency and hierarchical relationships between the various test intents in the target test intent set; and constructing a test intent graph with the test intents in the target test intent set as nodes and the relationships in the set of intent association relationships as edges, wherein each node in the test intent graph contains intent type information, target description information, and risk level.

[0009] Optionally, after constructing a test intent graph based on the fusion perception results, the risk level, code change frequency, historical defect density, and user impact of each node in the test intent graph are obtained to obtain four-dimensional feature parameters for each node; the test depth coefficient of each node is determined based on the four-dimensional feature parameters, wherein the test depth coefficient is used to quantify the test coverage depth of the function corresponding to the node; and the test strategy corresponding to the node is determined based on the numerical range of the test depth coefficient of each node.

[0010] Optionally, the test depth coefficient of each node is determined based on the feature parameters of the four dimensions, including: obtaining the weight coefficients corresponding to the risk level, code change frequency, historical defect density and user impact of each node; performing a weighted summation on the risk level, code change frequency, historical defect density and user impact of each node, and determining the test depth coefficient of the node based on the result of the weighted summation.

[0011] Optionally, each test case in the reference test case set is verified, and automatic repair is performed on test cases that fail verification until the repaired test cases pass verification. The verified test cases are then used as target test cases. This includes performing multiple verification operations on each test case in the reference test case set to obtain verification results. These multiple verification operations include at least syntax verification, semantic verification, reachability verification, and redundancy detection. Syntax verification verifies whether the test cases conform to preset syntax specifications, which include: the test case contains at least one operation step, each operation step uses a preset standard format, and the test case contains assertion statements. Semantic verification verifies whether the test cases conform to preset syntax specifications. The test data type and value range are verified to conform to business rules; reachability verification is used to verify whether the interface element location path in the test steps is valid, or whether the endpoint of the application interface can respond normally; redundancy detection is used to detect whether each test case in the reference test case set overlaps with the test coverage of the generated historical test cases; when the verification result indicates that the test case has failed the verification, an automatic repair operation is performed on the test case to obtain the repaired test case; the repaired test case is used as a new test case, and multiple verification operations are re-executed until the verification passes or the preset retry limit is reached, and the test case that passes the verification is used as the target test case.

[0012] Optionally, after extracting multiple candidate test intents from the fusion perception results to form a candidate test intent set, a confidence score is calculated for each candidate test intent based on document clarity, defect association strength, and user behavior popularity. Candidate test intents with confidence scores higher than a preset threshold are marked as high-confidence intents. High-confidence intents are preferentially added to the test intent map.

[0013] Optionally, after extracting multiple candidate test intentions from the fusion perception results to form a candidate test intention set, the matching degree between each candidate test intention in the candidate test intention set and the intention template in the intention pattern library is detected. The intention pattern library stores intention templates accumulated in historical tests. When the matching degree between any candidate test intention and the intention template in the intention pattern library is lower than the target threshold, the candidate test intention is added to the intention pattern library as a new intention template.

[0014] Optionally, after determining the test depth coefficient of each node based on the feature parameters of the four dimensions, the risk propagation impact of each node on the neighboring nodes is determined along the edges of the test intent graph. The risk propagation impact is equal to the propagation coefficient multiplied by the product of the risk level of the neighboring node and the edge weight. The risk level and risk propagation impact of each node are added together to obtain the updated risk level of the node. Based on the updated risk level of each node, the test depth coefficient of the node is re-determined.

[0015] Optionally, the review agents quantify and score the N test case candidate sets from multiple dimensions, including: calling M review agents, where M is an integer greater than 1, and each review agent corresponds to different test logic; obtaining the N test case candidate sets generated by the N test case agents for each node in the test intent graph; constructing a preliminary scoring matrix based on the initial scores of each review agent for the N test case candidate sets, where the M rows of the preliminary scoring matrix correspond to the M review agents and the N columns correspond to the N test case candidate sets; controlling each review agent to adjust its own scores for each test case candidate set based on the scores of other review agents in the preliminary scoring matrix, generating an adjusted scoring matrix; and weighting and summing the scores of each test case candidate set in the adjusted scoring matrix to obtain the final comprehensive score for each test case candidate set.

[0016] Optionally, an error pattern library is constructed, which stores the correspondence between error types and remediation solutions; error feature vectors of test cases that failed verification are obtained; target remediation solutions are retrieved from the error pattern library based on the error feature vectors, wherein the similarity between the error type corresponding to the target remediation solution and the error feature vector is greater than a preset similarity; remediation operations are performed on the test cases that failed verification according to the target remediation solution to obtain the remediated test cases; and the successfully remediated test cases and their corresponding target remediation solutions are mapped together and then added to the error pattern library.

[0017] According to another aspect of the embodiments of this application, a multi-agent test case generation device based on a test intent graph is also provided, comprising: an acquisition unit for acquiring multiple heterogeneous data sources, wherein the multiple heterogeneous data sources include at least: requirement specifications, historical defect databases, and user behavior logs; a first processing unit for performing data standardization, entity alignment, and cross-validation on the multiple heterogeneous data sources to obtain a fusion perception result, wherein the fusion perception result is used to characterize a unified knowledge representation formed after the fusion processing of the multiple heterogeneous data sources; and a graph construction unit for constructing a test intent graph based on the fusion perception result, wherein the test intent graph is a directed graph structure with test intents as nodes and the relationships between test intents as edges, and is used to... The system is designed to represent the hierarchical organization of test requirements. It includes: a calling unit, which calls N test case agents to generate test case candidate sets for each node in the test intent graph, resulting in N test case candidate sets, where N is an integer greater than 1, and each test case agent generates one test case candidate set; a scoring unit, where a review agent quantitatively scores the N test case candidate sets from multiple dimensions and selects one test case candidate set as a reference test case set based on the scoring results; and a verification unit, which verifies each test case in the reference test case set and automatically repairs test cases that fail verification until the repaired test cases pass verification, using the verified test cases as target test cases.

[0018] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, which stores a computer program, wherein when the computer program is executed, the device where the computer-readable storage medium is located executes the above-described multi-agent test case generation method based on test intent graph.

[0019] According to another aspect of the embodiments of this application, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when one or more programs are executed by one or more processors, the one or more processors cause the one or more processors to execute the above-described multi-agent test case generation method based on test intent graph.

[0020] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program or instructions, which, when executed by a processor, implement the above-described method for generating multi-agent test cases based on test intent graphs.

[0021] As described above, firstly, this application acquires multiple heterogeneous data sources and performs data standardization, entity alignment, and cross-validation to form a fusion perception result, establishing a unified knowledge representation foundation and providing structured input for subsequent processing. Secondly, based on the fusion perception result, a test intent graph is constructed. This graph uses test intents as nodes and the relationships between intents as edges, forming a systematic test requirement guidance framework. This provides a clear requirement organization structure and hierarchical guidance for the test case generation process. Finally, multiple test case agents are invoked to generate candidate test cases, which are then quantitatively scored and selected by a review agent. This helps improve the efficiency and quality of test case generation through concurrent generation and competitive selection mechanisms. Furthermore, automatic verification and repair further enhance the output quality of test cases, thus solving the technical problem of low generation efficiency caused by the lack of a systematic guidance framework in the test case generation process in existing technologies. Attached Figure Description

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

[0023] Figure 1 This is a flowchart of an optional multi-agent test case generation method based on test intent graph according to an embodiment of this application;

[0024] Figure 2 This is the overall architecture diagram of the test case generation system provided in the embodiments of this application;

[0025] Figure 3 This is a schematic diagram of the test intent map provided in the embodiments of this application;

[0026] Figure 4 This is a flowchart of the self-verification and repair closed-loop process of the use cases provided in the embodiments of this application;

[0027] Figure 5 This is a schematic diagram of the competitive review mechanism provided in the embodiments of this application;

[0028] Figure 6 This is a schematic diagram of an optional multi-agent test case generation device based on a test intent graph, according to an embodiment of this application. Detailed Implementation

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

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

[0031] According to an embodiment of this application, an embodiment of a multi-agent test case generation method based on test intent graph is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0032] Figure 1 This is a flowchart of an optional multi-agent test case generation method based on test intent graphs according to an embodiment of this application, such as... Figure 1 As shown, the method includes the following steps:

[0033] Step S101: Obtain multiple types of heterogeneous data sources, including at least: requirements specification documents, historical defect databases, and user behavior logs.

[0034] For example, the heterogeneous data sources acquired by the test case generation system refer to data sets collected from different sources with varying formats and structures, including at least three categories: requirements specifications, historical defect databases, and user behavior logs. The requirements specifications describe the functional and non-functional requirements of the software in unstructured or semi-structured natural language text; the historical defect database records defect information discovered in historical testing in structured tables, including defect descriptions, root cause analyses, remediation plans, and the corresponding functional modules; and the user behavior logs record the user's behavioral trajectory in actual operation in time-series text format, including operation paths, click heatmaps, and abnormal exit records. By acquiring these three types of data sources, the test case generation system provides multi-dimensional input information for subsequent integrated perception.

[0035] In some embodiments, the test case generation system can read the requirement specification document from the requirement management platform via an application programming interface (API). This requirement specification document is organized in a standard format and includes information such as functional requirement numbers, requirement descriptions, priority markers, and acceptance criteria. The test case generation system stores the read requirement specification document as a raw text file and simultaneously parses its structured fields (such as requirement number and priority) to create an index, facilitating subsequent entity identification and correlation analysis. For systems containing a large number of requirement documents, the test case generation system supports batch import and incremental updates, helping to improve the real-time nature of requirement information.

[0036] In other embodiments, the test case generation system obtains a historical defect database from the defect tracking system via a database connection and acquires user behavior logs through a log collection interface. The test case generation system is configured with a scheduled data synchronization task to synchronize newly added and modified defect records from the defect tracking system daily and collect user behavior logs from the previous day's log server. For the historical defect database, the test case generation system extracts fields such as defect description, associated functional module, defect severity, and repair status; for the user behavior logs, the test case generation system extracts fields such as user identifier, operation time, operation page, operation type, and session duration. The test case generation system stores the acquired data into corresponding data warehouse tables, maintaining the integrity and traceability of the original data.

[0037] Step S102 involves standardizing, aligning, and cross-validating data from multiple heterogeneous data sources to obtain the fusion perception results.

[0038] Among them, the fusion perception result is used to characterize the unified knowledge representation formed after multiple heterogeneous data sources are fused.

[0039] For example, the test case generation system performs data standardization, entity alignment, and cross-validation on the acquired heterogeneous data sources to generate a fusion-aware result. Data standardization involves converting data sources of different formats into a unified knowledge representation format, enabling subsequent processing to access data consistently. Entity alignment identifies entities in different data sources that refer to the same functional module or risk point and establishes correspondences between them. Cross-validation cross-verifies information from different data sources, enhancing confidence when multiple data sources point to the same conclusion. Through these processes, the test case generation system integrates information scattered across multiple data sources into a unified knowledge representation.

[0040] In some embodiments, the test case generation system first converts the requirements specification, historical defect database, and user behavior logs into a unified key-value pair format. For the requirements specification, the system extracts fields such as functional module name, functional description, and priority; for the historical defect database, the system extracts fields such as the defect's module, defect description, and defect severity; for the user behavior logs, the system extracts fields such as access frequency, operation path, and exception type. After unifying the format, the system identifies entities belonging to the same functional module in different data sources through name matching and semantic similarity calculation. For example, when the "user login" module in the requirements specification, the "login authentication" defect in the defect database, and the "login" operation in the user logs are identified as the same entity, the system establishes a relationship between them.

[0041] In other embodiments, the test case generation system performs cross-validation to improve the credibility of data fusion. The system detects whether the same risk point is pointed to by multiple data sources but not described by other data sources. For example, when the historical defect database shows that "payment timeout" related defects occur frequently, and the abnormal exit rate of the "payment page" in the user behavior log is significantly high, but the requirements specification does not explicitly require the "payment timeout" scenario, the system determines that the risk point is of high priority and increases its risk level in the fusion perception result. The system integrates the data after standardization, entity alignment, and cross-validation into a unified knowledge representation, which is output as the fusion perception result. This fusion perception result includes the attribute information, risk level, and cross-data source relationships of each functional entity, providing structured input for subsequent test intent extraction.

[0042] Step S103: Construct a test intent graph based on the fusion perception results. The test intent graph is a directed graph structure with test intents as nodes and the relationships between test intents as edges, used to represent the hierarchical organization of test requirements.

[0043] For example, the test case generation system constructs a test intent graph based on the fused perception results. Here, a test intent refers to the goal or purpose of testing and verifying power system functions. Each test intent includes an intent type (e.g., verifying functional correctness, exploring abnormal scenarios, regressing existing functions), a goal description (e.g., verifying that the substation telemetry data acquisition function can accurately report data under normal operating conditions), and a risk level. Directed edges between nodes represent the relationships between test intents, including inclusion relationships (a parent intent contains a child intent), prerequisite relationships (the execution of one intent depends on the completion of another intent), and mutual exclusion relationships (two intents cannot be executed simultaneously). By constructing a directed graph structure, the test case generation system organizes the dispersed power system functional requirements into a hierarchical test intent network.

[0044] In some embodiments, the test case generation system constructs a test intent graph for the telemetry communication module of a smart substation. The system extracts the root intent "Verify telemetry communication function" from the fused sensing results, and then generates three sub-intents based on the functional decomposition in the requirements specification: "Verify telemetry data upload," "Verify remote control command issuance," and "Verify communication interruption reconnection." The risk level of "Verify communication interruption reconnection" is marked as high because historical defect data shows this scenario occurs frequently in power system fault records. The system establishes the relationships between sub-intents according to the logic of the power system communication protocol: "Verify telemetry data upload" and "Verify remote control command issuance" are parallel, while the execution of "Verify communication interruption reconnection" requires verification based on normal communication. The system organizes these intent nodes and relationships into a directed graph, forming a complete test intent graph.

[0045] In other embodiments, the test case generation system constructs a test intent graph for the bus voltage control function of the power dispatch automation system. The system extracts the root intent "Verify bus voltage control function" from the fused sensing results and generates sub-intents "Verify normal voltage regulation," "Verify voltage over-limit alarm," and "Verify reactive power compensation trigger" based on high-frequency operation paths in user behavior logs. "Verify voltage over-limit alarm" is driven by voltage over-limit accident records in the historical defect database, and its risk level is elevated to high. "Verify normal voltage regulation" is marked as a prerequisite intent for "Verify voltage over-limit alarm," indicating that the normal regulation function must be verified correctly before verifying the over-limit alarm scenario. The system establishes directed edges between intent nodes according to the power system control logic, forming a hierarchical test intent graph to guide the direction and focus of subsequent test case generation.

[0046] Step S104: For each node in the test intent graph, call N test case agents to generate test case candidate sets respectively, resulting in N test case candidate sets, where N is an integer greater than 1, and each test case agent is used to generate one test case candidate set.

[0047] For example, the test case generation system calls N test case agents to generate a candidate set of test cases for each node in the test intent graph. Here, a test case agent refers to an automated generation unit employing different test design strategies, and each test case agent encapsulates a specific test case construction algorithm. N is an integer greater than 1, indicating that the system simultaneously launches multiple parallel test case agents for each intent node. Different test case agents can employ different test design methods, such as equivalence class partitioning, boundary value analysis, scenario-driven testing, and random testing. Through concurrent generation by multiple agents, the test case generation system obtains multiple candidate sets of test cases with different styles within the same timeframe, providing candidate solutions for subsequent selection.

[0048] In some embodiments, the test case generation system, targeting the "Verify Telemetry Data Upload" intent node in the remote communication module of a smart substation, invokes three test case agents to generate candidate test case sets. The first test case agent uses an equivalence class partitioning strategy to categorize telemetry data types into three classes: analog quantities, state quantities, and cumulative quantities, generating a candidate test case set covering all categories, containing a total of 8 test cases. The second test case agent uses a boundary value analysis strategy to generate a candidate test case set covering the lower limit, upper limit, and critical values ​​for the telemetry data range (e.g., voltage 0kV to 500kV), containing a total of 5 test cases. The third test case agent uses an anomaly scenario-driven strategy to simulate abnormal situations such as communication interruption, data exceeding limits, and format errors, generating a candidate test case set covering fault recovery scenarios, containing a total of 6 test cases. The system executes the three test case agents in parallel, obtaining three candidate test case sets.

[0049] In other embodiments, the test case generation system, targeting the "verify bus voltage control function" intent node in the power dispatch automation system, invokes two test case agents to generate test case candidate sets. The first agent employs a scenario-driven strategy, generating a test case candidate set simulating typical operation processes based on high-frequency operation paths recorded in user behavior logs. This set includes 10 test cases covering scenarios such as normal voltage regulation, voltage over-limit alarms, and reactive power compensation triggering. The second agent uses a combined testing strategy, combining different values ​​of voltage control parameters (target voltage value, adjustment step size, response time, etc.) to generate a test case candidate set covering the parameter combination space, totaling 12. The two agents execute independently and in parallel, each completing candidate set generation within a preset timeout period. The test case generation system collects all candidate sets returned by the agents, providing input data for subsequent review and selection.

[0050] Step S105: The review agent performs quantitative scoring on the N test case candidate sets from multiple dimensions, and selects one test case candidate set as the reference test case set based on the scoring results.

[0051] For example, the test case generation system calls a review agent to quantitatively score N candidate test case sets from multiple dimensions, and selects the best candidate test case set as the reference test case set based on the scoring results. The review agent is an automated evaluation unit responsible for evaluating and selecting the candidate test case set, possessing multi-dimensional quantitative scoring capabilities. These dimensions include coverage, quality, efficiency, and risk. Coverage assesses the completeness of the candidate set's description of the test intent objectives; quality assesses the readability, executability, and clarity of expected results of the test cases in the candidate set; efficiency assesses the conciseness of the candidate set, i.e., covering as many test scenarios as possible with as few test cases as possible; and risk assesses the candidate set's coverage of high-risk scenarios. The test case generation system selects the optimal candidate test case set from multiple candidate solutions through the comprehensive scoring by the review agent.

[0052] In some embodiments, the test case generation system, targeting the "Verify Telemetry Data Upload" intent node in the remote communication module of a smart substation, invokes a review agent to quantitatively score three candidate test case sets. The first candidate set is generated using an equivalence class partitioning strategy, with scores such as 85 for coverage (covering analog, state, and cumulative data), 90 for quality (clear test case structure), 75 for efficiency (8 test cases), and 70 for risk (insufficient coverage of abnormal scenarios). The second candidate set is generated using a boundary value analysis strategy, with scores such as 70 for coverage, 85 for quality, 80 for efficiency (5 test cases), and 65 for risk. The third candidate set is generated using an abnormal scenario-driven strategy, with scores such as 90 for coverage, 80 for quality, 70 for efficiency (6 test cases), and 95 for risk (covering high-risk scenarios such as communication interruption and data violation). After comprehensive calculation by the review agent, the third candidate set, with the highest score, is selected as the reference test case set.

[0053] In some other embodiments, the test case generation system, targeting the "verify bus voltage control function" intent node in the power dispatch automation system, invokes a review agent to quantitatively score two candidate test case sets. The first candidate set is generated using a scenario-driven strategy, for example, a coverage score of 95 (covering multiple scenarios such as normal regulation, over-limit alarms, and reactive power compensation), a quality score of 85, an efficiency score of 70 (for 10 test cases), and a risk score of 90. The second candidate set is generated using a combined testing strategy, for example, a coverage score of 85, a quality score of 80, an efficiency score of 60 (for 12 test cases), and a risk score of 75. The review agent uses a weighted comprehensive model for calculation, for example, a coverage weight of 0.3, a quality weight of 0.25, an efficiency weight of 0.2, and a risk weight of 0.25. After calculation, the first candidate set scores 86.5 points, and the second candidate set scores 79.5 points. The first candidate set is selected as the reference test case set.

[0054] Step S106: Verify each test case in the reference test case set, and perform automatic repair on test cases that fail verification until the repaired test cases pass verification. The verified test cases are then used as target test cases.

[0055] For example, the test case generation system verifies each test case in the reference test case set and automatically repairs any test cases that fail verification until the repaired test cases pass verification. The verified test cases are then used as target test cases. Verification refers to the process of evaluating the syntactic correctness, semantic rationality, step reachability, and redundancy of test cases using preset checking rules. Automatic repair refers to the automatic adjustment and correction of test cases based on the types of problems found during verification. Through this iterative closed loop of verification and repair, the test case generation system ensures that the final output target test cases are executable and effective.

[0056] In some embodiments, the test case generation system performs verification operations on a reference test case set for the remote communication module of the smart substation. For example, the system can perform syntax verification on each test case sequentially, checking whether the operation steps are complete, whether the preconditions are clear, and whether assertions exist. Suppose two test cases fail syntax verification: one test case lacks the expected assertion, and the other test case uses an undefined element location path in its operation steps. The system performs automatic repair operations on these two test cases: for the test case lacking assertions, it adds the assertion "expecting telemetry data to be consistent with the source"; for the test case with the invalid element location path, it corrects the location path according to the interface element library. After the repair is completed, the system re-verifies these two test cases. After confirming that both pass, it outputs all verified test cases as target test cases.

[0057] In other embodiments, the test case generation system performs verification operations on a reference test case set of the power dispatch automation system. For example, the system performs semantic verification and reachability verification on 10 test cases in the test case set. Suppose that semantic verification finds that one test case uses an invalid voltage value (more than twice the rated voltage of the bus), and determines that the test data does not comply with business rule constraints. Reachability verification finds that the bus identifier referenced in one test case does not exist in the target system, and determines that the step is unreachable. The system automatically repairs this: replacing the invalid voltage value with the upper limit of the preset valid value range; replacing the non-existent bus identifier with an actual bus identifier existing in the system. After repair and re-verification, one test case still fails due to a bus identifier mismatch. The system performs a second repair and passes the verification. The system outputs all the verified test cases as target test cases and stores the repair records in the log for subsequent analysis.

[0058] For example, Figure 2 This is the overall architecture diagram of the test case generation system provided in the embodiments of this application. For example... Figure 2As shown, the architecture comprises four core layers: a data fusion and perception layer, an intent graph construction layer, a competition generation layer, and a verification and repair layer. The data fusion and perception layer processes three heterogeneous data sources: requirements specifications, historical defect databases, and user behavior logs, outputting fusion and perception results. The intent graph construction layer, connected to the data fusion and perception layer, receives the fusion and perception results and constructs a test intent graph. The competition generation layer, connected to the intent graph construction layer, includes multiple test case agents and one review agent, used to generate a candidate set of test cases and select the best one. The verification and repair layer, connected to the competition generation layer, verifies and automatically repairs the test cases, outputting the final test cases.

[0059] In some embodiments, data standardization, entity alignment, and cross-validation are performed on multiple heterogeneous data sources, including: converting the multiple heterogeneous data sources into a unified knowledge representation format to obtain multiple standardized data; identifying entities belonging to the same functional module from the multiple standardized data and establishing relationships between entities to obtain associated fused data; and performing cross-validation on the associated fused data. When the same risk point is detected to be pointed to by both the historical defect database and user behavior logs and is not described in the requirements specification, the priority of the risk point is increased to obtain the fused perception result.

[0060] For example, a unified knowledge representation format refers to converting data from different sources and with different structures into key-value pairs with the same field structure. An entity refers to a specific functional module or risk point described in the data, such as "bus voltage control," "telemetry data acquisition," or "communication interruption handling." Cross-validation is the process of discovering overlooked risk points or prioritizing risks by comparing information from different data sources.

[0061] In some embodiments, the test case generation system processes various data sources from smart substations. The system converts functional descriptions in the requirements specification into key-value pairs of "functional module name, functional description, priority"; converts defect records in the historical defect database into key-value pairs of "defect module, defect description, severity"; and converts operation records in user behavior logs into key-value pairs of "operation module, operation type, frequency". After format unification, the system identifies the "telecommunication" entity appearing in all three data sources, establishes relationships between them, and forms fused data. The system can also perform cross-validation on the fused data. For example, it finds that the risk point "communication interruption and reconnection" appears 23 times in the historical defect database and ranks third in abnormal exit rate in user behavior logs, but the requirements specification only provides a general description of "communication should be stable". The system determines this risk point as high priority and increases its risk level in the fused perception results.

[0062] In other embodiments, the test case generation system processes data sources from the power dispatch automation system. For example, the system extracts functional entities such as "bus voltage control," "reactive power regulation," and "over-limit alarm" from the requirements specification, defect entities such as "voltage over-limit," "regulation timeout," and "data jump" from the defect database, and functional entities corresponding to high-frequency operations from user behavior logs. After completing entity alignment, the system found that the number of defect records for "voltage over-limit handling" continued to increase, and the dwell time on the "voltage over-limit alarm" page in the user logs increased significantly. However, the requirements specification only described the normal voltage regulation process and did not specify the handling logic after the limit was exceeded in detail. The system marked this risk point as high priority and added "verify voltage over-limit alarm" as an independent test intent in the fusion perception results.

[0063] In some embodiments, constructing a test intent graph based on the fusion perception results includes: extracting multiple candidate test intents from the fusion perception results to form a candidate test intent set; performing matching and attribute completion operations on the candidate test intents in the candidate test intent set based on an intent pattern library to obtain a target test intent set, wherein the matching operation is used to calculate the similarity between the candidate test intents and intent templates in the intent pattern library, and the attribute completion operation is used to supplement the missing attribute information of the candidate test intents based on the matched intent templates; obtaining a set of intent association relationships corresponding to the target test intent set, wherein the set of intent association relationships includes the dependency relationships and hierarchical relationships between the various test intents in the target test intent set; and constructing a test intent graph with the test intents in the target test intent set as nodes and the relationships in the set of intent association relationships as edges, wherein each node in the test intent graph contains intent type information, target description information, and risk level.

[0064] For example, the intent pattern library is a pre-stored collection of test intent templates, each containing an intent type, a target description format, and commonly used attribute fields. The matching operation is used to calculate the similarity between candidate test intents and intent templates, and the attribute completion operation is used to supplement missing attribute information of candidate test intents, such as risk level and preconditions, based on the matched templates.

[0065] In some embodiments, the test case generation system extracts multiple candidate test intents from the fusion perception results, forming a candidate test intent set. The system matches each candidate test intent with intent templates in the intent pattern library, calculates semantic similarity, and selects the template with the highest similarity as the matching result. Based on the matched intent templates, the system automatically completes the missing attribute information in the candidate test intents, including the intent type classification (verification, exploration, or regression), the standardized format of the target description, and the initial assignment of the risk level. After completing the attribute completion, the system analyzes the logical relationships between the test intents, including inclusion, precondition, and mutual exclusion relationships, generating a set of intent association relationships. The system constructs a test intent graph with test intents as nodes and association relationships as directed edges, where each node contains intent type information, target description information, and risk level.

[0066] In other embodiments, after obtaining the target test intent set, the test case generation system determines the dependencies and hierarchical relationships between the test intents based on functional logic and business rules. For test intents with parent-child relationships, the system establishes an inclusion edge pointing from the parent intent to the child intent; for test intents with execution order dependencies, the system establishes a precedence edge pointing from the preceding intent to the following intent; for test intents that cannot be executed simultaneously, the system establishes a bidirectional mutual exclusion edge. The system organizes all test intent nodes and associated edges into a directed graph structure, forming a test intent graph. This graph presents the hierarchical organization of test requirements, where the root node represents the core test objective, child nodes represent decomposed sub-objectives, and edges represent the logical relationships between objectives. The test case generation system uses this graph as a guiding framework for subsequent test case generation.

[0067] For example, Figure 3 This is a schematic diagram of the test intent map provided in the embodiments of this application. For example... Figure 3 As shown, the test intent graph is a directed graph structure with test intents as nodes and the relationships between intents as edges. The root intent node is located at the center of the graph, representing the core test objective. The root intent node is decomposed into multiple sub-intent nodes, which are connected by different types of edges. Edge types include containment (parent node points to child node), prerequisite (one node points to another, indicating execution dependency), and mutual exclusion (bidirectional edges, indicating that they cannot be executed simultaneously). Each intent node contains intent type information, objective description information, and risk level. This directed graph structure is used to represent the hierarchical organization of test requirements, providing a guiding framework for subsequent test case generation.

[0068] In some embodiments, after constructing a test intent graph based on the fusion perception results, the risk level, code change frequency, historical defect density, and user impact of each node in the test intent graph are obtained to obtain four-dimensional feature parameters for each node; the test depth coefficient of each node is determined based on the four-dimensional feature parameters, wherein the test depth coefficient is used to quantify the test coverage depth of the function corresponding to the node; and the test strategy corresponding to the node is determined based on the numerical range of the test depth coefficient of each node.

[0069] For example, after constructing the test intent map, the test case generation system obtains the risk level, code change frequency, historical defect density, and user impact of each node, thus obtaining four-dimensional characteristic parameters for each node. Then, based on these parameters, it determines the test depth coefficient for each node and determines the corresponding test strategy based on the numerical range of the test depth coefficient. Specifically, the code change frequency is derived from the commit records of the version control system, reflecting the activity level of the functional module; the historical defect density is derived from the statistical results of the defect database, reflecting the quality risk of the functional module; and the user impact is derived from the analysis results of user behavior logs, reflecting the usage frequency and importance of the functional module.

[0070] In some embodiments, the test case generation system acquires four-dimensional feature parameters of each node in the test intent map. For each node, the system calculates a test depth coefficient by weighting and summing its risk level, code change frequency, historical defect density, and user impact according to preset weight coefficients. The test depth coefficient is a value between 0 and 1, used to quantify the test coverage depth required for the function corresponding to that node. The system presets two thresholds: a first threshold (e.g., 0.8) and a second threshold (e.g., 0.5). When the test depth coefficient of a node is greater than or equal to the first threshold, the system assigns a deep testing strategy to that node, requiring complete equivalence class partitioning, boundary value analysis, and abnormal scenario coverage for the function; when the test depth coefficient is between the second and first thresholds, a standard testing strategy is assigned, covering the main normal processes and key boundary conditions; when the test depth coefficient is less than the second threshold, a lightweight testing strategy is assigned, covering only the core normal processes.

[0071] In other embodiments, the test case generation system dynamically adjusts the allocation of test resources based on the test depth coefficient value of each node. The system first calculates the test depth coefficient for all nodes, identifying high-risk nodes (test depth coefficient greater than or equal to a first threshold) and low-risk nodes (test depth coefficient less than a second threshold). For high-risk nodes, the system increases the number of test cases generated in subsequent test case generation phases, requiring coverage of more test dimensions; for low-risk nodes, the system appropriately reduces the number of test cases generated to avoid resource waste caused by over-testing. After completing the test strategy allocation, the system uses the target test strategy for each node as a guide for subsequently calling the test case agent to generate a candidate set of test cases, tilting test resources towards high-risk areas, thereby improving test efficiency.

[0072] In some embodiments, the test depth coefficient of each node is determined based on the feature parameters of four dimensions, including: obtaining the weight coefficients corresponding to the risk level, code change frequency, historical defect density and user impact of each node; performing a weighted summation on the risk level, code change frequency, historical defect density and user impact of each node, and determining the test depth coefficient of the node based on the result of the weighted summation.

[0073] For example, the weighting coefficients are preset configurable parameters used to adjust the degree of influence of different dimensional factors on the test depth coefficient. The sum of the four weighting coefficients equals 1. The larger the weighted sum, the deeper the test coverage required for the function corresponding to that node.

[0074] In some embodiments, the test case generation system can use default weight configurations, such as setting the weight of risk level to 0.4, code change frequency to 0.2, historical defect density to 0.2, and user impact to 0.2. For a node in the test intent map, its risk level is 0.8, code change frequency is 0.6, historical defect density is 0.7, and user impact is 0.5. The system calculates the weighted sum: 0.4×0.8 + 0.2×0.6 + 0.2×0.7 + 0.2×0.5 = 0.32 + 0.12 + 0.14 + 0.10 = 0.68. The system uses this calculation result as the test depth coefficient for that node. Since 0.68 is between 0.5 and 0.8, the system assigns a standard test strategy to that node.

[0075] In other embodiments, the test case generation system allows users to adjust weight coefficients based on actual testing needs. When the testing team is particularly focused on high-risk features, the weight of the risk level can be increased to 0.6, while the weights of other dimensions are correspondingly decreased. After obtaining the user-configured weight coefficients, the system calculates the weighted sum of each node in the same way. For nodes with high risk levels but low scores in other dimensions, adjusting the weights will significantly improve their test depth coefficients, resulting in more comprehensive test coverage. After calculation, the system stores the test depth coefficients of all nodes in the test intent graph for use in subsequent test strategy selection steps. Users can also dynamically adjust the weight coefficients based on historical test performance feedback to make the calculation of the test depth coefficients more closely match the actual project needs.

[0076] In some embodiments, each test case in the reference test case set is verified, and automatic repair is performed on test cases that fail verification until the repaired test cases pass verification. The verified test cases are then used as target test cases. This includes performing multiple verification operations on each test case in the reference test case set to obtain verification results.

[0077] The various verification operations include at least syntax verification, semantic verification, reachability verification, and redundancy detection. Syntax verification verifies whether test cases conform to preset syntax specifications, which include: test cases containing at least one operation step, each operation step using a preset standard format, and test cases containing assertion statements. Semantic verification verifies whether the data type and value range of test data conform to business rule constraints. Reachability verification verifies whether the interface element location path in the test steps is valid, or whether the endpoint of the application interface can respond normally. Redundancy detection detects whether each test case in the reference test case set overlaps in test coverage with previously generated historical test cases.

[0078] When the verification result indicates that the test case has failed verification, an automatic repair operation is performed on the test case to obtain a repaired test case. The repaired test case is then used as a new test case, and multiple verification operations are re-executed until the verification passes or the preset retry limit is reached. The test case that passes verification is then used as the target test case.

[0079] In some embodiments, the test case generation system sequentially performs syntax verification, semantic verification, reachability verification, and redundancy detection on test cases in a reference test case set. For test cases that fail syntax verification, the system marks their specific problems (e.g., missing assertion statements, incorrect step format); for test cases that fail semantic verification, the system marks the specific locations where the test data does not conform to business rules; for test cases that fail reachability verification, the system marks unlocatable interface elements or inaccessible interface endpoints; for test cases that fail redundancy detection, the system marks overlapping existing test cases. The system collects all verification results and generates a verification report for that test case.

[0080] In other embodiments, the test case generation system performs automatic repair operations on test cases that fail verification based on the verification results. For syntax issues, the system automatically completes missing assertions or corrects step formats according to preset syntax templates; for semantic issues, the system replaces invalid test data with data within the valid value range according to the business rule library; for reachability issues, the system corrects the location path or endpoint address according to the interface element library or interface definition library; for redundancy issues, the system deletes duplicate test cases or merges test cases with overlapping coverage. After the repair is completed, the system uses the repaired test case as a new test case and re-executes various verification operations. The system repeats this process until the test case passes all verifications or reaches the preset retry limit, and outputs the verified test case as the target test case.

[0081] Figure 4 This is a flowchart illustrating the self-verification and repair closed-loop process of use cases provided in the embodiments of this application. For example... Figure 4 As shown, the process includes four stages: verification, judgment, repair, and iteration. The verification stage performs four operations on the test cases: syntax verification, semantic verification, reachability verification, and redundancy detection. The judgment stage determines whether the test cases pass based on the verification results: if they pass, they proceed to the output stage; otherwise, they proceed to the repair stage. The repair stage retrieves the corresponding repair solution from the error mode library based on the type of verification failure and performs automatic repair operations. After repair, the repaired test cases are returned to the verification stage for re-verification, forming a closed-loop iteration until verification passes or the preset retry limit is reached, at which point the target test case is output.

[0082] In some embodiments, after extracting multiple candidate test intents from the fusion perception results to form a candidate test intent set, a confidence score is calculated for each candidate test intent based on document clarity, defect association strength, and user behavior popularity. Candidate test intents with confidence scores higher than a preset threshold are marked as high-confidence intents. High-confidence intents are preferentially added to the test intent map.

[0083] For example, after extracting candidate test intents from the fusion perception results, the test case generation system calculates a confidence score for each candidate test intent. Here, document clarity refers to the clarity with which the test intent is described in the requirements specification; defect association strength refers to the closeness of the association between the test intent and defect records in the historical defect database; and user behavior popularity refers to the frequency with which the function corresponding to the test intent appears in user behavior logs. The test case generation system weights and sums these three dimensions according to preset weights to obtain the confidence score for each candidate test intent. A higher confidence score indicates a higher degree of credibility in the cross-validation of multi-source data for the test intent.

[0084] In some embodiments, the test case generation system acquires the document clarity, defect association strength, and user behavior popularity for each candidate test intent. The system assesses document clarity based on the completeness of the function description in the requirements specification and the existence of clear functional requirements and acceptance criteria; assesses defect association strength based on the number and severity of defects related to the function in the historical defect database; and assesses user behavior popularity based on the frequency and depth of access to the function in user behavior logs. The system uses preset weighting coefficients to perform a weighted sum of the values ​​in the three dimensions to obtain a confidence score. Candidate test intents with confidence scores higher than a preset threshold are marked as high-confidence intents.

[0085] In other embodiments, when constructing a test intent graph, the test case generation system prioritizes adding high-confidence intents to the graph. For candidate test intents with confidence scores below a preset threshold, the system either temporarily withholds them from the graph or places them in a pending confirmation state for manual review. For candidate test intents with confidence scores near the threshold, the system can mark them in the graph to prompt testers to focus on them during subsequent reviews. This mechanism ensures that test intents with higher confidence in the multi-source data fusion perception results receive priority test coverage, allowing test resources to be allocated to high-risk, high-frequency functional areas. Through confidence-based filtering, the test case generation system can effectively filter out low-quality or low-priority candidate test intents, thereby helping to improve the accuracy and usability of the test intent graph.

[0086] In some embodiments, after extracting multiple candidate test intentions from the fusion perception results to form a candidate test intention set, the matching degree between each candidate test intention in the candidate test intention set and the intention template in the intention pattern library is detected, wherein the intention pattern library stores intention templates accumulated in historical tests; when the matching degree between any candidate test intention and the intention template in the intention pattern library is lower than the target threshold, the candidate test intention is added to the intention pattern library as a new intention template.

[0087] For example, the intent pattern library is a knowledge base used to store intent templates accumulated in historical tests. Each intent template contains intent type, target description format, and commonly used attribute fields. Matching degree is used to measure the similarity between a candidate test intent and existing intent templates. When the matching degree of a candidate test intent with all existing intent templates is lower than a preset threshold, it means that the candidate test intent cannot be covered by existing templates, and the system adds it as a new intent template to the intent pattern library, thereby realizing the dynamic expansion of the pattern library.

[0088] In some embodiments, the test case generation system performs a matching calculation between candidate test intents and each intent template in the intent pattern library one by one. The system uses a semantic similarity algorithm to compare the similarity between the target description of the candidate test intent and the target description format of the template. The calculated similarity value is between 0 and 1, with a higher value indicating greater similarity. The system takes the maximum value among all matching results as the matching degree between the candidate test intent and the intent pattern library. When the matching degree is lower than a preset threshold, it is determined that the candidate test intent cannot be effectively covered by existing templates. The system organizes the intent type, target description, and attribute information of the candidate test intent into a standard format and adds it to the intent pattern library as a new intent template for use in subsequent test intent matching.

[0089] In other embodiments, the test case generation system periodically maintains and optimizes the intent pattern library. When multiple newly added intent templates have similar characteristics, the system can merge or generalize them to form more universal templates. The system can also prioritize the intent pattern library based on the frequency of template usage, with frequently used templates participating in matching calculations first to improve matching efficiency. Through this dynamic update mechanism, the intent pattern library can continuously accumulate experience as the test project progresses, continuously enhancing its coverage of newly emerging test intent types, reducing misses in subsequent test intent matching, and thus improving the automation and accuracy of test intent graph construction.

[0090] In some embodiments, after determining the test depth coefficient of each node based on the feature parameters of the four dimensions, the risk propagation impact of each node on the neighboring nodes is determined along the edges of the test intent graph, wherein the risk propagation impact is equal to the propagation coefficient multiplied by the product of the risk level of the neighboring node and the edge weight; the risk level and the risk propagation impact of each node are added together to obtain the updated risk level of the node; and the test depth coefficient of the node is re-determined based on the updated risk level of each node.

[0091] For example, the propagation coefficient is a preset constant greater than 0 and less than 1, used to control the propagation strength of risk between adjacent nodes; the edge weight is used to characterize the association strength between two nodes, with stronger associations resulting in greater risk propagation impact. This mechanism allows risk to spread reasonably along the functional dependency chain, avoiding the isolated assessment of the risk of a single node.

[0092] In some embodiments, the test case generation system traverses all nodes in the test intent graph. For each node, the system obtains the risk level and corresponding edge weights of all its neighboring nodes, calculates the risk propagation contribution of each neighboring node to the node (propagation coefficient multiplied by the neighboring node's risk level multiplied by the edge weight), and sums the contribution values ​​of all neighboring nodes to obtain the total risk propagation impact on the node. The system adds the node's original risk level to the risk propagation impact to obtain the updated risk level. When multiple preceding nodes of a node have high risk levels, the node obtains a higher updated risk level through risk propagation, thereby achieving deeper test coverage in subsequent tests.

[0093] In other embodiments, after the test case generation system updates the risk levels of all nodes, it recalculates the test depth coefficient for each node based on the updated risk levels. The system uses the same weighted summation formula, replacing the original risk level with the updated one, and calculates the new test depth coefficient along with other dimension parameters (code change frequency, historical defect density, user impact). Due to the impact of risk propagation, nodes with lower risk levels may receive higher test depth coefficients due to the presence of adjacent high-risk nodes. The system then reallocates test strategies to each node based on the new test depth coefficients. Through this risk propagation mechanism, test resources can be reasonably diffused along the functional dependency chain to relevant nodes, making the test coverage of the entire test intent graph more balanced and effective.

[0094] In some embodiments, a review agent quantifies and scores N test case candidate sets from multiple dimensions, including: invoking M review agents, where M is an integer greater than 1, and each review agent corresponds to different test logic; obtaining N test case candidate sets generated by the N test case agents for each node in the test intent graph; constructing a preliminary scoring matrix based on the initial scores of each review agent for the N test case candidate sets, where the M rows of the preliminary scoring matrix correspond to the M review agents and the N columns correspond to the N test case candidate sets; controlling each review agent to adjust its own scores for each test case candidate set based on the scores of other review agents in the preliminary scoring matrix, generating an adjusted scoring matrix; and weighting and summing the scores of each test case candidate set in the adjusted scoring matrix to obtain the final comprehensive score for each test case candidate set.

[0095] For example, the test case generation system invokes M review agents to quantitatively score N candidate test cases. Each review agent corresponds to different testing logic; for example, some review agents prioritize coverage, some prioritize test case quality, some prioritize execution efficiency, and some prioritize risk coverage. The M review agents independently score the N candidate test cases, forming a preliminary scoring matrix. This matrix has M rows corresponding to the M review agents, N columns corresponding to the N candidate test cases, and matrix elements representing the score values ​​given by the corresponding review agent for the corresponding candidate case. The preliminary scoring matrix records the independent judgment results from different review perspectives.

[0096] In some embodiments, after the test case generation system constructs an initial scoring matrix, it controls each review agent to obtain the scoring results of other review agents in the matrix. Each review agent compares its own score with the scores of other review agents to identify candidate sets with significant score differences. For candidate sets with score differences exceeding a preset threshold, the review agent adjusts its own score for that candidate set based on the scores of other review agents to make the scores more consistent. During the adjustment process, the review agent can use methods such as weighted averaging, median calculation, or confidence-based correction. After multiple rounds of adjustment, the system generates an adjusted scoring matrix.

[0097] In other embodiments, the test case generation system performs a weighted summation of the scores for each candidate test case set in the adjusted scoring matrix. The system assigns weights to each review agent based on their historical scoring accuracy or a user-preset authority level. For each candidate test case set, the system weights and sums the adjusted scores from all review agents according to their respective weights to obtain the final comprehensive score for that candidate set. The system sorts all candidate sets by their final comprehensive scores and outputs the test case candidate set with the highest score as the optimal selection result. Through the independent scoring and mutual adjustment mechanism of multiple review agents, the system can integrate evaluation perspectives from different testing logics, improving the objectivity and reliability of the selection result.

[0098] For example, Figure 5 This is a schematic diagram of the competitive review mechanism provided in an embodiment of this application. Figure 5 As shown, the mechanism includes a candidate generation phase and a review and selection phase. In the candidate generation phase, multiple use case agents work in parallel to generate a set of candidate test cases for the same intent node, with each agent corresponding to a different test design strategy. In the review and selection phase, multiple review agents independently score the candidate sets, with each agent corresponding to different test logic. The review agents exchange and adjust their scores through a debate mechanism, then perform a weighted summation of the adjusted scores, and select the best candidate set of test cases as the output based on the final summation score.

[0099] In some embodiments, the test case generation system can construct an error pattern library, which stores the correspondence between error types and remediation solutions. Then, it obtains the error feature vectors of test cases that failed verification; based on the error feature vectors, it retrieves target remediation solutions from the error pattern library, wherein the similarity between the error type corresponding to the target remediation solution and the error feature vector is greater than a preset similarity. Finally, the test case generation system performs remediation operations on the test cases that failed verification according to the target remediation solutions, obtaining remediated test cases. After establishing a mapping relationship between the successfully remediated test cases and their corresponding target remediation solutions, it adds them to the error pattern library.

[0100] For example, the test case generation system builds an error pattern library, which stores the correspondence between error types and remediation solutions. Error types include syntax errors (such as missing assertion statements or incorrect step formatting), semantic errors (such as test data exceeding the valid range), and reachability errors (such as invalid location paths for interface elements). Each error type is associated with one or more remediation solutions, and each remediation solution contains a specific sequence of remediation operations. The initial content of the error pattern library can be pre-configured by expert experience or continuously enriched through successful remediation cases during system operation.

[0101] In some embodiments, the test case generation system acquires test cases that failed verification, extracts their error features, and generates an error feature vector. The error feature vector includes information such as the location of the error, the error type identifier, and the semantic features of the error context. The system matches the error feature vector with error types stored in an error pattern library and calculates the similarity. When an error type with a similarity greater than a preset threshold exists, the system recalls the corresponding repair scheme as the target repair scheme. The system performs repair operations on the failed test cases according to the repair operation sequence in the target repair scheme to obtain repaired test cases. The system resubmits the successfully repaired test cases for verification, and after confirmation, treats them as valid output.

[0102] In other embodiments, the test case generation system adds successfully fixed test cases and their corresponding target fixes to an error pattern library after establishing a mapping relationship. When a fix successfully fixes a test case, the system stores the error feature vector of that test case and the fix used as a new experience record in the error pattern library. If the error pattern library already contains records of the same error type, the system can use new successful cases as supplementary data to optimize the priority of fixes or adjust the order of fix operations. Through this continuous learning and accumulation mechanism, the coverage and fix accuracy of the error pattern library continuously improve with the number of times the system is used. When encountering similar error types in the future, it can recall fixes more quickly and accurately, thereby reducing the need for manual intervention.

[0103] According to another aspect of the embodiments of this application, Figure 6 This is a schematic diagram of an optional multi-agent test case generation device based on a test intent graph according to an embodiment of this application, such as... Figure 6 As shown, the device includes: an acquisition unit 601, used to acquire multiple heterogeneous data sources, wherein the multiple heterogeneous data sources include at least: requirement specifications, historical defect databases, and user behavior logs; a first processing unit 602, used to perform data standardization, entity alignment, and cross-validation on the multiple heterogeneous data sources to obtain fusion perception results, wherein the fusion perception results are used to characterize the unified knowledge representation formed after the fusion processing of multiple heterogeneous data sources; a graph construction unit 603, used to construct a test intent graph based on the fusion perception results, wherein the test intent graph is a directed graph structure with test intents as nodes and the relationships between test intents as edges, used to characterize the hierarchical organization of test requirements; and a call unit. Unit 604 is used to call N test case agents to generate test case candidate sets for each node in the test intent graph, resulting in N test case candidate sets, where N is an integer greater than 1, and each test case agent is used to generate one test case candidate set; scoring unit 605 is used for the review agent to quantitatively score the N test case candidate sets from multiple dimensions, and selects the best test case candidate set as the reference test case set based on the scoring results; verification unit 606 is used to verify each test case in the reference test case set, and automatically repairs the test cases that fail verification until the repaired test cases pass verification, and the verified test cases are used as target test cases.

[0104] Optionally, the first processing unit 602 includes: a format conversion subunit, used to convert multiple heterogeneous data sources into a unified knowledge representation format to obtain multiple types of standardized data; an entity recognition subunit, used to identify entities belonging to the same functional module from the multiple types of standardized data and establish the association relationship between entities to obtain the associated fused data; and a cross-validation subunit, used to perform cross-validation on the associated fused data, and when the same risk point is detected to be pointed to by both the historical defect database and user behavior logs and is not described in the requirements specification, the priority of the risk point is increased to obtain the fused perception result.

[0105] Optionally, the graph construction unit 603 includes: an extraction subunit, used to extract multiple candidate test intentions from the fusion perception results to form a candidate test intention set; a first processing subunit, used to perform matching and attribute completion operations on the candidate test intentions in the candidate test intention set based on the intention pattern library to obtain a target test intention set, wherein the matching operation is used to calculate the similarity between the candidate test intentions and the intention templates in the intention pattern library, and the attribute completion operation is used to supplement the missing attribute information of the candidate test intentions according to the matched intention templates; an acquisition subunit, used to acquire the intention association relationship set corresponding to the target test intention set, wherein the intention association relationship set includes the dependency relationship and hierarchical relationship between each test intention in the target test intention set; and a graph construction subunit, used to construct a test intention graph with the test intentions in the target test intention set as nodes and the relationships in the intention association relationship set as edges, wherein each node in the test intention graph contains intention type information, target description information, and risk level.

[0106] Optionally, the multi-agent test case generation device based on the test intent graph includes: a parameter acquisition unit, used to acquire the risk level, code change frequency, historical defect density, and user impact of each node in the test intent graph, to obtain four-dimensional feature parameters for each node; a first determination unit, used to determine the test depth coefficient of each node based on the four-dimensional feature parameters, wherein the test depth coefficient is used to quantify the test coverage depth of the function corresponding to the node; and a second determination unit, used to determine the test strategy corresponding to the node based on the numerical range of the test depth coefficient of each node.

[0107] Optionally, the first determining unit includes: a weight coefficient acquisition subunit, used to acquire the weight coefficients corresponding to the risk level, code change frequency, historical defect density, and user impact of each node; and a first determining subunit, used to perform a weighted summation of the risk level, code change frequency, historical defect density, and user impact of each node, and determine the test depth coefficient of the node based on the weighted summation result.

[0108] Optionally, the verification unit 606 includes: a verification subunit, used to perform multiple verification operations on each test case in the reference test case set to obtain a verification result, wherein the multiple verification operations include at least syntax verification, semantic verification, reachability verification, and redundancy detection; a repair subunit, used to perform automatic repair operations on the test case when the verification result indicates that the test case has failed verification, to obtain a repaired test case; and a re-verification subunit, used to re-execute multiple verification operations on the repaired test case as a new test case until the verification passes or a preset retry limit is reached, and the test case that passes the verification is used as the target test case.

[0109] Syntax validation verifies whether test cases conform to preset syntax specifications, which include: test cases containing at least one operation step, each operation step using a preset standard format, and test cases containing assertion statements; semantic validation verifies whether the data type and value range of test data conform to business rule constraints; reachability validation verifies whether the interface element location path in the test step is valid, or whether the endpoint of the application interface can respond normally; redundancy detection verifies whether each test case in the reference test case set overlaps in test coverage with previously generated historical test cases.

[0110] Optionally, the multi-agent test case generation device based on the test intent graph further includes: a confidence score determination unit, used to calculate a confidence score for each candidate test intent based on document clarity, defect correlation strength and user behavior popularity, to obtain a confidence score for each candidate test intent; a marking unit, used to mark candidate test intents with confidence scores higher than a preset threshold as high-confidence intents; and an intent processing unit, used to prioritize adding high-confidence intents to the test intent graph.

[0111] Optionally, the multi-agent test case generation device based on the test intent graph further includes: a detection unit, used to detect the matching degree between each candidate test intent in the candidate test intent set and the intent template in the intent pattern library, wherein the intent pattern library stores intent templates accumulated in historical tests; and an intent template processing unit, used to add the candidate test intent as a new intent template to the intent pattern library when the matching degree between any candidate test intent and the intent template in the intent pattern library is lower than a target threshold.

[0112] Optionally, the multi-agent test case generation device based on the test intent graph further includes: a third determining unit, used to determine the risk propagation impact of adjacent nodes on each node along the edges of the test intent graph, wherein the risk propagation impact is equal to the propagation coefficient multiplied by the product of the risk level of the adjacent node and the edge weight; a level updating unit, used to add the risk level and risk propagation impact of each node to obtain the updated risk level of the node; and a coefficient updating unit, used to redetermine the test depth coefficient of the node according to the updated risk level of each node.

[0113] Optionally, the scoring unit 605 includes: an agent invocation subunit for invoking M review agents, where M is an integer greater than 1, and each review agent corresponds to different test logic; a candidate set acquisition subunit for acquiring N test case candidate sets generated by N test case agents for each node in the test intent graph; a scoring matrix construction subunit for constructing a preliminary scoring matrix based on the initial scores of each review agent for the N test case candidate sets, where the M rows of the preliminary scoring matrix correspond to the M review agents, and the N columns correspond to the N test case candidate sets; a scoring adjustment subunit for controlling each review agent to adjust its own scores for each test case candidate set based on the scores of other review agents in the preliminary scoring matrix, generating an adjusted scoring matrix; and a scoring update subunit for weighted summation of the scores of each test case candidate set in the adjusted scoring matrix to obtain the final comprehensive score for each test case candidate set.

[0114] Optionally, the multi-agent test case generation device based on test intent graph further includes: a pattern library construction unit for constructing an error pattern library, wherein the error pattern library stores the correspondence between error types and repair solutions; an error feature vector acquisition unit for acquiring error feature vectors of test cases that failed verification; a solution recall unit for recalling target repair solutions from the error pattern library based on error feature vectors, wherein the similarity between the error type corresponding to the target repair solution and the error feature vector is greater than a preset similarity; a test case repair unit for performing repair operations on the test cases that failed verification according to the target repair solution to obtain repaired test cases; and a test case processing unit for adding successfully repaired test cases and their corresponding target repair solutions to the error pattern library after establishing a mapping relationship.

[0115] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, which stores a computer program, wherein when the computer program is executed, the device where the computer-readable storage medium is located executes the above-described multi-agent test case generation method based on test intent graph.

[0116] According to another aspect of the embodiments of this application, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when one or more programs are executed by one or more processors, the one or more processors cause the one or more processors to execute the above-described multi-agent test case generation method based on test intent graph.

[0117] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program or instructions, which, when executed by a processor, implement the above-described method for generating multi-agent test cases based on test intent graphs.

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

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

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

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

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

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

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

Claims

1. A method for generating multi-agent test cases based on test intent graphs, characterized in that, include: Acquire multiple types of heterogeneous data sources, wherein the multiple types of heterogeneous data sources include at least: requirements specification documents, historical defect databases, and user behavior logs; Data standardization, entity alignment, and cross-validation are performed on the multiple heterogeneous data sources to obtain fusion perception results, wherein the fusion perception results are used to characterize the unified knowledge representation formed after the multiple heterogeneous data sources are fused. A test intent graph is constructed based on the fusion perception results. The test intent graph is a directed graph structure with test intents as nodes and the relationships between test intents as edges, used to represent the hierarchical organization of test requirements. For each node in the test intent graph, N test case agents are invoked to generate test case candidate sets, resulting in N test case candidate sets, where N is an integer greater than 1, and each test case agent is used to generate one test case candidate set. The review agent quantifies and scores the N test case candidate sets from multiple dimensions, and selects one test case candidate set as the reference test case set based on the scoring results; Each test case in the reference test case set is verified, and automatic repair is performed on test cases that fail verification until the repaired test cases pass verification. The verified test cases are then used as target test cases.

2. The method according to claim 1, characterized in that, Data standardization, entity alignment, and cross-validation are performed on the aforementioned heterogeneous data sources, including: The various heterogeneous data sources are converted into a unified knowledge representation format to obtain various standardized data. Identify entities belonging to the same functional module from the multiple types of standardized data, establish the association relationship between the entities, and obtain the associated fused data; Cross-validation is performed on the associated fused data. When the same risk point is detected to be pointed to by both the historical defect database and the user behavior log, but not described by the requirement specification, the priority of the risk point is increased to obtain the fused perception result.

3. The method according to claim 1, characterized in that, Based on the fusion perception results, a test intent graph is constructed, including: Multiple candidate test intentions are extracted from the fused perception results to form a candidate test intention set; Based on the intent pattern library, the candidate test intents in the candidate test intent set are matched and attribute completion operations are performed to obtain the target test intent set. The matching operation is used to calculate the similarity between the candidate test intents and the intent templates in the intent pattern library, and the attribute completion operation is used to supplement the missing attribute information of the candidate test intents according to the matched intent templates. Obtain a set of intent association relationships corresponding to the target test intent set, wherein the set of intent association relationships includes the dependency and hierarchical relationships between the various test intents in the target test intent set; The test intent graph is constructed using test intents in the target test intent set as nodes and relationships in the intent association set as edges. Each node in the test intent graph contains intent type information, target description information, and risk level.

4. The method according to claim 1, characterized in that, After constructing the test intent graph based on the fusion perception results, the method further includes: The risk level, code change frequency, historical defect density, and user impact of each node in the test intent map are obtained, resulting in four-dimensional feature parameters for each node. The test depth coefficient of each node is determined based on the feature parameters of the four dimensions, wherein the test depth coefficient is used to quantify the test coverage depth of the function corresponding to the node; The testing strategy for each node is determined based on the range of the test depth coefficient.

5. The method according to claim 4, characterized in that, The test depth coefficient for each node is determined based on the feature parameters of the four dimensions, including: Obtain the weight coefficients corresponding to the risk level, code change frequency, historical defect density, and user impact of each node; The risk level, code change frequency, historical defect density, and user impact of each node are weighted and summed, and the test depth coefficient of the node is determined based on the weighted sum.

6. The method according to claim 1, characterized in that, Each test case in the reference test case set is verified, and automatic repair is performed on test cases that fail verification until the repaired test cases pass verification. The verified test cases are then used as target test cases, including: Perform multiple verification operations on each test case in the reference test case set to obtain verification results. The multiple verification operations include at least syntax verification, semantic verification, reachability verification, and redundancy detection. The syntax validation is used to verify whether the test cases conform to the preset syntax specifications, which include: the test cases contain at least one operation step, each operation step adopts a preset standard format, and the test cases contain assertion statements. The semantic verification is used to verify whether the data type and value range of the test data comply with the business rule constraints. The reachability verification is used to verify whether the interface element location path in the test step is valid, or whether the endpoint of the application interface can respond normally. The redundancy detection is used to detect whether each test case in the reference test case set overlaps in test coverage with previously generated historical test cases; When the verification result indicates that the test case has failed verification, an automatic repair operation is performed on the test case to obtain a repaired test case. The repaired test cases are used as new test cases, and the various verification operations are re-executed until the verification passes or the preset retry limit is reached. The test cases that pass the verification are used as the target test cases.

7. The method according to claim 3, characterized in that, After extracting multiple candidate test intents from the fused perception results to form a candidate test intent set, the method further includes: For each candidate test intent, a confidence score is calculated by weighting the document clarity, defect correlation strength, and user behavior popularity. Candidate test intentions with confidence scores higher than a preset threshold are marked as high-confidence intentions; The high-confidence intent is preferentially added to the test intent map.

8. The method according to claim 3, characterized in that, After extracting multiple candidate test intents from the fused perception results to form a candidate test intent set, the method further includes: The matching degree between each candidate test intent in the candidate test intent set and the intent template in the intent pattern library is detected, wherein the intent pattern library stores intent templates accumulated in historical tests; When the matching degree between any candidate test intent and the intent template in the intent pattern library is lower than the target threshold, the candidate test intent is added to the intent pattern library as a new intent template.

9. The method according to claim 4, characterized in that, After determining the test depth coefficient for each node based on the feature parameters of the four dimensions, the method further includes: Along the edges of the test intent graph, determine the risk propagation impact of each node on its neighboring nodes, wherein the risk propagation impact is equal to the propagation coefficient multiplied by the product of the risk level of the neighboring node and the edge weight. The updated risk level of a node is obtained by adding the risk level of each node to the risk propagation impact. The test depth coefficient for each node is redefined based on its updated risk level.

10. The method according to claim 1, characterized in that, The review agent quantitatively scores the N candidate test cases from multiple dimensions, including: Call M review agents, where M is an integer greater than 1, and each review agent corresponds to different test logic; Obtain N candidate test cases generated by N test case agents for each node in the test intent graph; Based on the initial scores given by each review agent to the N test case candidate sets, a preliminary scoring matrix is ​​constructed, wherein the M rows of the preliminary scoring matrix correspond to the M review agents, and the N columns correspond to the N test case candidate sets; Each review agent is controlled to adjust its own score for each test case candidate set based on the scores of other review agents in the preliminary score matrix, thereby generating an adjusted score matrix; The scores of each test case candidate set in the adjusted scoring matrix are weighted and combined to obtain the final comprehensive score of each test case candidate set.

11. The method according to claim 6, characterized in that, The method further includes: Construct an error mode library, wherein the error mode library stores the correspondence between error types and repair solutions; Obtain the error feature vector of test cases that failed verification; The target repair solution is recalled from the error pattern library based on the error feature vector, wherein the similarity between the error type corresponding to the target repair solution and the error feature vector is greater than a preset similarity. According to the target repair plan, the test cases that failed to verify are repaired to obtain the repaired test cases; After establishing a mapping relationship between successfully repaired test cases and their corresponding target repair solutions, they are added to the error mode library.

12. A multi-agent test case generation device based on test intent graph, characterized in that, include: The acquisition unit is used to acquire multiple types of heterogeneous data sources, wherein the multiple types of heterogeneous data sources include at least: requirements specification documents, historical defect databases and user behavior logs; The first processing unit is used to perform data standardization, entity alignment and cross-validation on the multiple heterogeneous data sources to obtain a fusion perception result, wherein the fusion perception result is used to characterize the unified knowledge representation formed after the multiple heterogeneous data sources are fused. The graph construction unit is used to construct a test intent graph based on the fusion perception results. The test intent graph is a directed graph structure with test intents as nodes and the relationships between test intents as edges, used to represent the hierarchical organization of test requirements. The calling unit is used to call N test case agents to generate test case candidate sets for each node in the test intent graph, resulting in N test case candidate sets, where N is an integer greater than 1, and each test case agent is used to generate one test case candidate set. The scoring unit is used by the review agent to quantitatively score the N test case candidate sets from multiple dimensions, and select one test case candidate set as the reference test case set based on the scoring results. The verification unit is used to verify each test case in the reference test case set, and to automatically repair test cases that fail verification until the repaired test cases pass verification. The verified test cases are then used as target test cases.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed, the device containing the computer-readable storage medium performs the multi-agent test case generation method based on test intent graph as described in any one of claims 1 to 11.

14. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to perform the multi-agent test case generation method based on test intent graphs as described in any one of claims 1 to 11.

15. A computer program product, characterized in that, It includes a computer program or instructions that, when executed by a processor, implement the multi-agent test case generation method based on test intent graphs as described in any one of claims 1 to 11.

Images