AI-based test requirement analysis and use case generation method and system

Abstract

The application relates to the technical field of software testing, and discloses a test requirement analysis and use case generation method and system based on AI, which comprises the following steps: acquiring a new and old version requirement document set, constructing a corresponding logic flow graph, generating a logic increment difference graph through graph isomorphism matching and determining an overall influence area; acquiring a stock test case set and mapping the stock test case set into a stock use case path set, identifying an affected path, executing path geometric deformation and expansion, and generating a final evolution path; finally, calculating evolution path comprehensive energy loss, determining a use case evolution state, obtaining a final test case set, and establishing a use case evolution pedigree table; the application realizes activation and evolution of stock test assets, and reduces the maintenance cost of government software regression testing.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and more specifically, to an AI-based method and system for test requirements analysis and test case generation. Background Technology

[0002] Software testing is a core component in ensuring the functional integrity, business logic compliance, and operational stability of software products. The design, iteration, and management of test cases directly determine the coverage quality and execution efficiency of software testing. This is especially true in the field of government software, where frequent business process adjustments, stringent compliance requirements, and short version iteration cycles place extremely high demands on the iterative adaptability, business coverage accuracy, and asset reusability of test cases. With the rapid development of artificial intelligence technology, AI-based automated test case generation technology has become a mainstream R&D direction for improving software testing efficiency and reducing manual testing costs.

[0003] Among existing related technologies, Chinese patent application CN121524042A discloses an AI-based automated test case generation method and system. This solution converts the original requirement document into an image format, then uses a multimodal large model to identify and integrate textual and non-textual features in the document to form a parsed requirement document. Through processes such as dynamic segmentation of the requirement document and generation of test case titles, a large language model is used to finally generate complete test cases corresponding to the requirement document, achieving automated test case generation and significantly shortening the test case production cycle. Chinese patent CN120066974B discloses an AI-based test case generation method, device, system, and medium. This solution uses keywords to traverse the requirement document to distinguish different requirement modules, combines an OCR module to extract content information from the flowchart, and uses the segmented document as input to an AI model to generate test cases and corresponding inference information. This improves the efficiency of test case generation while providing testers with a complete inference process to verify the reliability of the test cases.

[0004] However, existing AI-based test case generation technologies all revolve around automating the generation of new test cases based on new version requirement documents. They lack a structured relationship and adaptive adaptation mechanism between existing test cases and version requirement changes, resulting in certain technical shortcomings in scenarios with high-frequency iterations of government software requirements. When software requirements iterate from an older version to a newer one, existing test cases do not become completely invalid. Instead, they experience gradual semantic decay. That is, the core business logic originally designed to be covered by existing test cases may only cover the periphery of the original business logic due to changes in requirement processes, business entities, and execution conditions. In some cases, the test intent may even deviate from the new version's requirement logic, making it impossible to effectively verify the changed core business logic. When faced with such requirement changes, existing technologies can only update test cases by completely regenerating them. On the one hand, this method directly discards the expert experience and implicit testing knowledge of testers regarding business boundaries and abnormal scenarios contained in existing test cases, resulting in a waste of a large number of high-value testing assets. On the other hand, there is a lack of traceable logical inheritance between the newly generated test cases and the existing test cases, making it impossible to establish a complete evolution chain of test cases across version iterations. This makes it difficult to accurately locate the test coverage changes corresponding to requirement changes during regression testing, easily leading to problems such as missing test coverage for core change logic and repeated testing of non-change logic. This not only increases the maintenance cost of regression testing during the high-frequency iteration of government software, but also causes functional abnormalities and non-compliant business processing after the business system goes live due to incomplete test coverage, affecting the stability of government software operation and the continuity of public services. Summary of the Invention

[0005] To overcome the aforementioned shortcomings of existing technologies, this invention provides an AI-based method and system for test requirement analysis and test case generation. By constructing logical flow graphs corresponding to the old and new version requirements and performing graph isomorphic matching, it accurately identifies the overall impact area of ​​requirement changes, achieving a refined upgrade of requirement change analysis from text comparison to the logical topology level. Through path mapping, geometric deformation, and expansion optimization of existing test cases, it completes the adaptive evolution of existing test cases to new version requirements, fundamentally solving the semantic decay problem of existing test cases in scenarios with frequent changes.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] AI-based methods for test requirements analysis and test case generation include:

[0008] Obtain the old version requirement document set and the new version requirement document set, construct the old version logic flow diagram and the new version logic flow diagram, perform graph isomorphic matching on the old version logic flow diagram and the new version logic flow diagram to generate a logic incremental difference diagram, and determine the overall impact area based on the logic incremental difference diagram;

[0009] Obtain the existing test case set, map each existing test case in the existing test case set to the old version logic flow graph to form the existing test case path set, identify the affected path set from the existing test case path set according to the overall impact area, perform path geometric deformation on each old version test case path in the affected path set, and expand the deformed test case path to generate the final evolution path.

[0010] The structural and functional energy losses of the final evolution path are calculated to obtain the comprehensive energy loss. Based on the comprehensive energy loss and the change crossover ratio, the use case evolution status of the final evolution path is determined. Based on the use case evolution status, the final test case set is obtained and a use case evolution genealogy table is established.

[0011] The method for constructing the old version of the logic flow graph includes:

[0012] Obtain the old version requirement document set, perform natural language processing on each requirement document in the old version requirement document set, and extract the old version business entity set, old version business action set, and old version business condition set from each requirement document.

[0013] Based on the old version business entity set, old version business action set, and old version business condition set, construct the old version logical node set, analyze the dependency relationship between every two old version logical nodes in the old version logical node set, establish directed logical edges to form the old version logical edge set, and combine the old version logical node set and the old version logical edge set to construct the old version logical flow graph.

[0014] The method for generating a logical incremental difference graph by isomorphic matching of execution graphs includes:

[0015] Calculate the semantic similarity between each old version logical node in the old version logical node set and each new version logical node in the new version logical node set. Based on the semantic similarity, perform node matching to generate a node correspondence table, a set of nodes unique to the old version, and a set of nodes added in the new version.

[0016] Based on the node correspondence table, the set of nodes unique to the old version, and the set of nodes added in the new version, the node changes and edge changes between the old version logic flow graph and the new version logic flow graph are classified and marked to generate a logic increment difference graph.

[0017] The method for generating a node correspondence table, a set of nodes unique to the old version, and a set of nodes added in the new version by performing node matching based on semantic similarity includes:

[0018] Find the maximum semantic similarity and the corresponding new version logical node. Compare the maximum semantic similarity with the preset node matching threshold. If the maximum semantic similarity exceeds the node matching threshold, the match is successful. Mark the corresponding old version logical node and the new version logical node with the largest semantic similarity as corresponding node pairs and record the corresponding node pairs in the node correspondence table.

[0019] If the maximum semantic similarity does not exceed the node matching threshold, the corresponding old version logical node is marked as an old version unique node, and the old version unique node is added to the old version unique node set.

[0020] For new version logical nodes that are not matched by any old version logical nodes, mark them as new version new nodes and add them to the new version new node set.

[0021] The method for determining the overall area of ​​influence includes:

[0022] Identify directly affected regions from the logic increment difference graph, perform a breadth-first traversal of the directly affected regions in the old version logic flow graph to determine the indirectly affected regions, and merge the directly affected regions and the indirectly affected regions into the overall affected region.

[0023] The method for forming the set of existing use case paths includes:

[0024] Extract test step sequences from each existing test case in the existing test case set. Semantically match each test step in the test step sequence with the old version logical node set to determine the mapping node. Connect all mapping nodes according to the execution order of the test steps to form the old version test case path. Summarize all the old version test case paths to form the existing test case path set.

[0025] The method for identifying the affected path set includes:

[0026] Determine whether the path node set of each old version use case path in the existing use case path set intersects with the overall affected area. Mark the old version use case paths that intersect as affected paths and add them to the affected path set. Calculate the change crossover ratio of the affected paths.

[0027] The method for geometric deformation of the execution path includes:

[0028] For each old version logical node on each old version use case path in the affected path set, calculate the single-point traction vector according to the node correspondence table, and calculate the continuity repair vector. Superimpose the single-point traction vector and the continuity repair vector to obtain the final traction vector.

[0029] Based on the final traction vector of each old version logical node, the old version logical node is moved from its original position in the old version logical flow graph to its target position in the new version logical flow graph. Path breakpoints are marked, and all path breakpoints are summarized to form a breakpoint set. Based on the connection relationship of the original path segments, the connection is re-established in the new version logical flow graph to form the deformed use case path.

[0030] The method for generating the final evolution path includes:

[0031] Traverse the set of newly added nodes in the new version, determine the relevance of each newly added node in the new version to the modified use case path, insert the relevant newly added nodes in the new version as extension nodes into the modified use case path, and generate the final evolution path. The final evolution path inherits the set of breakpoints of the modified use case path.

[0032] The method for calculating the functional energy loss includes:

[0033] Extract all new version logical nodes traversed by the final evolution path to form an evolved node set, calculate the evolved semantic center vector of the evolved node set, extract all old version logical nodes traversed by the original old version use case path to form an original node set, calculate the original semantic center vector of the original node set, calculate the vector distance between the evolved semantic center vector and the original semantic center vector as the semantic drift distance, and calculate the functional energy loss based on the semantic drift distance.

[0034] An AI-based test requirements analysis and test case generation system is used to implement the aforementioned AI-based test requirements analysis and test case generation method. The system includes:

[0035] The logical difference analysis module is used to obtain the old version requirement document set and the new version requirement document set, construct the old version logical flow diagram and the new version logical flow diagram, perform graph isomorphism matching on the old version logical flow diagram and the new version logical flow diagram to generate a logical incremental difference diagram, and determine the overall impact area based on the logical incremental difference diagram;

[0036] Use Case Path Evolution Module: This module is used to obtain the existing test case set, map each existing test case in the existing test case set to the old version logic flow graph to form an existing test case path set, identify the affected path set from the existing test case path set based on the overall impact area, perform path geometric deformation on each old version test case path in the affected path set, and expand the deformed test case path to generate the final evolution path.

[0037] Evolution Status Determination Module: This module calculates the structural and functional energy losses of the final evolution path to obtain the comprehensive energy loss. Based on the comprehensive energy loss and the change crossover ratio, it determines the use case evolution status of the final evolution path. Based on the use case evolution status, it obtains the final test case set and establishes a use case evolution genealogy table.

[0038] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0039] This invention elevates the analysis of requirement changes from the textual level to the logical topology level by constructing logical flow graphs corresponding to the old and new versions of requirement documents and performing graph isomorphism matching. This accurately identifies the overall impact area of ​​requirement changes, providing a precise scope for the adaptation and optimization of existing test cases, avoiding the indiscriminate treatment of all test cases in traditional requirement change detection. By mapping existing test cases to paths on the logical flow graph and performing path geometric deformation and expansion, existing test cases can adaptively adapt to the requirement logic of the new version. This effectively solves the semantic decay problem of existing test cases in scenarios with frequent requirement changes in government software, eliminating the need for complete scrapping and regeneration. Under the premise of complete test cases, the testers' expert experience and implicit testing knowledge carried in the existing test cases are fully preserved, realizing the reuse and inheritance of test assets. Through the quantitative calculation of comprehensive energy loss and the hierarchical judgment of test case evolution status, the quantitative control of test case evolution adaptation effect is realized. Combined with the establishment of test case evolution spectrum table, the entire life cycle evolution trajectory of existing test cases is fully traced, ensuring the logical inheritance between new and old test cases. Ultimately, the continuous activation and iterative evolution of test assets are realized, significantly reducing the maintenance cost of regression testing in the continuous iteration of government software and avoiding the risk of test knowledge gap caused by frequent requirement changes. Attached Figure Description

[0040] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0041] Figure 1 A flowchart illustrating the AI-based test requirements analysis and test case generation method provided in this embodiment of the invention;

[0042] Figure 2 This is a schematic diagram of the logic flow graph topology provided in an embodiment of the present invention;

[0043] Figure 3 A flowchart for node matching and logical increment difference graph generation provided in this embodiment of the invention;

[0044] Figure 4 This is a schematic diagram illustrating the generation of key breakpoint patch paths provided in an embodiment of the present invention;

[0045] Figure 5 A functional module diagram of an AI-based test requirements analysis and test case generation system provided in an embodiment of the present invention. Detailed Implementation

[0046] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0047] Example 1

[0048] Please see Figure 1 As shown, this embodiment provides an AI-based method for test requirements analysis and test case generation, including:

[0049] Step S10: Obtain the old version requirement document set and the new version requirement document set, construct the old version logic flow diagram and the new version logic flow diagram, perform graph isomorphic matching on the old version logic flow diagram and the new version logic flow diagram to generate a logic incremental difference diagram, and determine the overall impact area based on the logic incremental difference diagram;

[0050] Further, step S10 includes:

[0051] Step S11: Obtain the old version requirement document set and the new version requirement document set, and construct the old version logic flow diagram and the new version logic flow diagram;

[0052] The method for constructing the old version logic flow graph is as follows: Obtain the old version requirement document set; perform natural language processing on each requirement document in the old version requirement document set; extract the old version business entity set, old version business action set, and old version business condition set from each requirement document; construct the old version logic node set based on the old version business entity set, old version business action set, and old version business condition set; analyze the dependency relationship between every two old version logic nodes in the old version logic node set; establish directed logical edges to form the old version logic edge set; combine the old version logic node set and the old version logic edge set to construct the old version logic flow graph.

[0053] The method for constructing the new version logic flow graph is as follows: obtain the new version requirement document set, construct the new version logic node set and the new version logic edge set, and combine the new version logic node set and the new version logic edge set to construct the new version logic flow graph;

[0054] See Figure 2 This is a schematic diagram of the logic flow graph topology provided in the embodiments of this application. Figure 2 The diagram illustrates the core element decomposition logic of the requirements document and the logical flow diagram of the directed graph structure built based on the decomposed elements, fully presenting the transformation process from requirements text to a structured logical topology. Specifically, the acquisition of the old version requirements document set and the new version requirements document set is achieved through the government software requirements management system. The old version requirements document set contains all requirement description files corresponding to the currently launched version, and the new version requirements document set contains all requirement description files corresponding to the version to be launched. Each requirements document is stored in the form of structured or semi-structured text, including functional descriptions, business process descriptions, constraint definitions, etc. Natural language processing is performed by combining a pre-trained language model with rule extraction. The pre-trained language model is used to identify semantic components in the requirements document, and rule extraction is used to extract specific types of information elements based on the terminology database and grammar templates of the government domain.

[0055] The extraction process for the old version's business entity set is as follows: Named entity recognition is performed on each sentence in the requirements document. The identified entity types include operation object entities and data object entities. Operation object entities refer to the specific things being operated on or processed in the requirements document, while data object entities refer to the information carriers involved in the requirements document. For example, in a government approval requirements document, operation object entities include application forms, approval forms, and public notice documents; data object entities include applicant information, approval opinions, and public notice periods. All identified entities are then aggregated to form the old version's business entity set. This set is... Figure 2 One of the core components of the requirements document module. The extraction process for the old version's business action set is as follows: Verb phrase extraction is performed on each sentence in the requirements document. Verb phrases represent operational actions performed on business entities. During extraction, auxiliary verbs and modal verbs must be excluded, retaining only the action words expressing the actual business operations. For example, in a government approval requirements document, business actions include submission, review, approval, rejection, public announcement, and archiving. All identified actions are summarized to form the old version's business action set, which is... Figure 2 One of the core components of the requirements document module. The extraction process for the old version's business condition set is as follows: Extracting conditional sentences and constraint descriptions from the requirements document. Conditional sentences include clauses introduced by conditional keywords, and constraint descriptions include prerequisites and restrictions for business execution. Each business condition represents a precondition for a business action or a constraint requirement during execution. For example, in a government approval requirements document, business conditions include complete application materials, compliance with approval authority, and no objections after the public notice period. All identified conditions are summarized to form the old version's business condition set. This set is... Figure 2It is one of the core components of the requirements document module.

[0056] The construction of the old version's logical node set followed the principle of constructing atomic business operation units, just as... Figure 2 As defined in the diagram, an entity + action + condition equals a logical node. Each logical node is an atomic business operation unit, represented by a circular node in the diagram. Each old version logical node consists of a triple. The first element of the triple is a business entity from the old version's business entity set, the second element is a business action from the old version's business action set, and the third element is zero or more business conditions from the old version's business condition set. When constructing the triple, there must be a semantic object-verb relationship between the business entity and the business action, and a semantic triggering relationship or constraint relationship between the business condition and the business action. For example, the triple of an old version logical node is "approval form + review + approval permission compliance," indicating that the review operation is performed on the approval form under the condition that the approval permission is met. This triple represents a complete atomic business operation unit, corresponding to... Figure 2 Approval form review nodes within the logic flow graph; similarly, Figure 2 The application form submission, public notice publication, rejection notice generation, and file archiving nodes are all logical nodes constructed based on the same triple rule. All triples that conform to the construction rule are aggregated to form an old version logical node set. Each old version logical node in the old version logical node set represents an indivisible business operation described in the requirements document.

[0057] Constructing the old version logical edge set requires analyzing whether there are dependencies between any two old version logical nodes in the old version logical node set. The types of dependencies include temporal dependencies, data dependencies, and conditional triggering dependencies. Figure 2 The text uses directed logical edges with arrows to represent dependencies between nodes, and also marks two core dependency types: sequential dependencies and conditional dependencies. A sequential dependency means that the execution of one older version of a logical node must occur after the execution of another older version of a logical node. The determination of sequential dependencies is based on the process order and temporal sequence described in the requirements document, as shown in... Figure 2 The directed logical edge from the application form submission node to the approval form review node is a concrete manifestation of temporal dependencies. Data dependencies refer to the requirement that the execution of an older version logical node requires the data result generated by the execution of another older version logical node. The determination of data dependencies is based on the flow of business entities between different logical nodes. Conditional triggering relationships refer to the requirement that the business condition of an older version logical node needs to be satisfied by the execution result of another older version logical node. The determination of conditional triggering relationships is based on the semantic association between the business condition and the execution results of other logical nodes, as shown in... Figure 2The directed logical edge from the approval form review node to the public notice document release node is a concrete manifestation of the conditional triggering relationship. For two old version logical nodes with any of the above dependencies, a directed logical edge is established. The starting node of the directed logical edge is the old version logical node that is depended upon, and the ending node is the old version logical node of the dependent party. The direction of the directed logical edge indicates the direction of dependency propagation. For example, there is a temporal dependency and a conditional triggering relationship between the approval form plus review plus approval permission and the public notice document plus release plus approval. The completion of the review operation is a prerequisite for the release operation, and the approval condition is satisfied by the execution result of the review operation. Therefore, a directed logical edge is established from the former to the latter. All directed logical edges are summarized to form the old version logical edge set, corresponding to... Figure 2 All directed arrows connecting the logical nodes in the middle.

[0058] The construction of the old version logic flow graph uses the old version logic node set as the vertex set and the old version logic edge set as the edge set, forming a directed graph structure. Figure 2 The framework of the logic flow graph (directed graph structure) on the right side is completely consistent. The number of vertices in the old version logic flow graph is equal to the number of old version logic nodes in the old version logic node set, and the number of edges in the old version logic flow graph is equal to the number of directed logical edges in the old version logic edge set. The topological structure of the old version logic flow graph fully expresses all the business logic and their interrelationships described in the old version requirements document set. The paths in the graph represent the execution sequence of the business process, such as... Figure 2 The sequence of steps—application form submission, approval document review, public notice issuance, and file archiving—constitutes a complete business process. The branches in the diagram represent conditional forks in the business process, such as… Figure 2 The approval form review node branches into two paths: the publication of the public notice and the generation of the rejection notice. These correspond to the forks in the approval process for the conditions of approval and rejection. The convergence in the diagram represents the merging point of multiple business processes.

[0059] The construction method for the new version's logic flow graph is the same as that for the old version. Natural language processing is performed on each requirement document in the new version's requirement document set to extract the new version's business entity set, business action set, and business condition set. Based on the extraction results, a new version logic node set is constructed. The dependency relationships between every two new version logic nodes are analyzed to establish directed logical edges, forming a new version logic edge set. The new version logic node set and the new version logic edge set are then combined to construct the new version's logic flow graph, following the same procedure throughout. Figure 2The presented logic flow graph outlines a complete set of construction rules, from the breakdown of requirements document elements to logical nodes, logical edges, and directed graph structures. The new version of the logic flow graph uses the same construction rules and the same graph structure as the old version, providing consistent input for subsequent graph isomorphism matching.

[0060] Step S11 elevates the analysis of requirement changes from the textual level to the logical topology level by converting the requirement document from unstructured natural language text into a structured directed graph representation. Traditional requirement change detection techniques, based on string comparison or keyword matching, can only identify superficial character differences in the text and cannot capture the deep logical structural changes caused by requirement changes. For example, changing from "approval before public announcement" to "public announcement before approval" is merely a word order change in the textual difference, which traditional techniques might identify as a minor modification. However, in terms of business logic, it represents a fundamental change in the process structure, reversing the temporal dependency between approval and public announcement. By constructing a logical flow graph, this change is represented in the graph structure as the interchange of the start and end nodes of directed logical edges, resulting in a significant change in the topology and accurately identifying this fundamental change. The construction of the logical flow graph integrates the scattered business logic elements described in the requirement document into a unified graph structure, eliminating ambiguity caused by differences in natural language expression in the requirement description and providing a formal analysis basis for subsequent steps.

[0061] See Figure 3 Step S12: Calculate the semantic similarity between each old version logical node in the old version logical node set and each new version logical node in the new version logical node set. Based on the semantic similarity, perform node matching to generate a node correspondence table, a set of nodes unique to the old version, and a set of nodes newly added in the new version. Based on the node correspondence table, the set of nodes unique to the old version, and the set of nodes newly added in the new version, classify and label the node changes and edge changes between the old version logical flow graph and the new version logical flow graph to generate a logical incremental difference graph.

[0062] Semantic similarity is calculated based on the text vector representations of business entities, actions, and conditions contained in the old and new versions of logical nodes. Text vectors are generated using a pre-trained word vector model, converting each business entity, action, and condition into a dense vector representation of fixed dimensions. For an old version logical node, its business entity vectors, action vectors, and all business condition vectors are concatenated or weighted to form the node semantic vector. The same method is used to generate the node semantic vector for each new version logical node. Semantic similarity is calculated using the cosine similarity formula. Cosine similarity measures the degree of consistency between two vectors in direction, with the result ranging from -1 to 1. The closer the value is to 1, the more consistent the directions of the two vectors, and the more semantically similar the corresponding logical nodes are.

[0063] The node matching process is as follows: For each old version logical node in the old version logical node set, traverse all new version logical nodes in the new version logical node set, calculate the semantic similarity between the old version logical node and each new version logical node, and find the maximum semantic similarity and the corresponding new version logical node. The maximum semantic similarity is compared with a preset node matching threshold. The node matching threshold is set based on the semantic distribution characteristics of government domain terms and is determined through threshold sensitivity analysis on a labeled dataset. A threshold that is too high may lead to misjudgments of actual matching node pairs due to subtle differences in expression, while a threshold that is too low may lead to misjudgments of semantically unrelated node pairs as matches. The specific implementation method of threshold sensitivity analysis is as follows: First, a node matching annotation dataset is constructed. The annotation dataset contains several pairs of old and new version logical nodes from historical version changes. Each pair of samples is judged and labeled as a positive or negative sample by domain experts based on business semantics. A positive sample indicates that the two logical nodes are semantically equivalent or corresponding, while a negative sample indicates that the two logical nodes are semantically unrelated. Then, a threshold traversal experiment is performed on the annotation dataset. The threshold traversal experiment increments the node matching threshold from 0 to 1 with a fixed step size of 0.05. A threshold value is selected, and the matching accuracy, matching recall, and F1 score are calculated at that threshold. Matching accuracy equals the number of correctly matched positive samples divided by the total number of samples judged as matches. Matching recall equals the number of correctly matched positive samples divided by the total number of positive samples in the labeled dataset. The F1 score is the harmonic mean of matching accuracy and matching recall. Finally, an accuracy-recall curve is plotted based on the threshold traversal experiment results. The threshold point with the largest F1 score is selected as the final node matching threshold. The threshold point with the largest F1 score represents the threshold setting that achieves the best balance between matching accuracy and recall. For example, the node matching threshold is set to 0.75. At this threshold, node pairs with different expressions but semantically equivalent meanings, such as "approval form + review" and "approval document + examination," can be correctly matched. At the same time, it can correctly distinguish semantically unrelated node pairs, such as "approval form + review" and "public notice document + publication."

[0064] If the maximum semantic similarity exceeds the node matching threshold, a successful match is achieved. The old version logical node and the new version logical node with the highest semantic similarity are marked as a corresponding node pair. A corresponding node pair indicates that the old version logical node has a semantically corresponding logical node in the new version requirements, and the business operation has been retained in the version change. The corresponding node pair is recorded in the node correspondence table, which stores the old version logical node as the key and the corresponding new version logical node as the value. If the maximum semantic similarity does not exceed the node matching threshold, the old version logical node is marked as an old version-unique node. An old version-unique node indicates that the old version logical node does not have a semantically corresponding logical node in the new version requirements, and the business operation has been deleted or fundamentally changed in the version change. The old version-unique node is added to the old version-unique node set. After node matching is completed, the new version logical node set is traversed. For new version logical nodes that are not matched by any old version logical nodes, they are marked as new version added nodes. New version added nodes indicate that the business operation is new content added to the new version requirements and does not exist in the old version requirements. The new version added nodes are added to the new version added node set.

[0065] The logical incremental difference graph is constructed based on a node mapping table, a set of nodes unique to the old version, and a set of nodes added in the new version. It records all topological changes during the evolution of the logical flow graph from the old version to the new version. Nodes in the logical incremental difference graph are divided into three categories: The first category is retained nodes, which are all old version logical nodes contained in the node mapping table. Retained nodes represent business operations that remain unchanged or undergo only minor adjustments during version changes. The second category is deleted nodes, which are all old version-unique nodes in the old version-unique node set. Deleted nodes represent business operations removed during version changes. The third category is added nodes, which are all new version added nodes in the new version added node set. Added nodes represent business operations newly introduced during version changes.

[0066] The edge marking process for the logical incremental difference graph is as follows: For each directed logical edge in the old version logical edge set, determine whether both the starting node and the ending node of the directed logical edge are retained nodes. If both the starting node and the ending node are retained nodes, further determine whether there is a corresponding directed logical edge in the new version logical edge set. The corresponding directed logical edge refers to the directed logical edge connecting the new version logical node corresponding to the starting node in the node correspondence table and the new version logical node corresponding to the ending node in the node correspondence table. If there is a corresponding directed logical edge in the new version logical edge set, mark the directed logical edge in the old version logical edge set as a retained edge, indicating that the dependency remains unchanged in the version change; if there is no corresponding directed logical edge in the new version logical edge set, mark the directed logical edge in the old version logical edge set as a deleted edge, indicating that the dependency is removed in the version change. If at least one of the starting node or the ending node is a deleted node, the directed logical edge is automatically marked as a deleted edge, because the dependency will inevitably no longer exist after the endpoint of the dependency is removed. After the edge marking is completed, the new version logical edge set is traversed. For directed logical edges that do not correspond to any directed logical edges marked as retained edges in the old version logical edge set, they are marked as new edges. New edges indicate that the dependency relationship is a newly established logical association in the new version requirements.

[0067] Step S12 uses graph isomorphic matching technology to make the correspondence between the old and new versions of the logical flow graph explicit, transforming version change analysis from full graph comparison to incremental difference analysis. Traditional requirement change detection requires comparing all content of the old and new versions one by one, which is computationally complex and makes it difficult to distinguish the importance of changes. By constructing a node correspondence table and classifying nodes into three categories (retained nodes, deleted nodes, and added nodes), the change type is made clear. By constructing a logical incremental difference graph and classifying edges into three categories (retained edges, deleted edges, and added edges), changes in dependencies are traceable, providing accurate topological change information for subsequent identification of the scope of change impact. Semantic similarity calculation uses vectorization, which, compared to keyword-based exact matching, can identify logical nodes with different expressions but semantic equivalence, avoiding misjudgments caused by differences in requirement document writing styles. The reasonable setting of the node matching threshold strikes a balance between matching accuracy and recall, ensuring that the identification of corresponding node pairs is neither missed nor falsely reported.

[0068] Step S13: Identify the directly changed regions from the logic increment difference graph, perform a breadth-first traversal of the directly changed regions in the old version logic flow graph to determine the indirectly affected regions, and merge the directly changed regions and the indirectly affected regions into the overall affected region.

[0069] The identification of directly affected regions involves extracting old version logical nodes directly impacted by version changes from the logical incremental difference graph. All deleted nodes and all deleted edges connected to old version logical nodes in the logical incremental difference graph are identified and defined as directly affected regions. These regions consist of two parts: the first part comprises all old version-specific nodes marked as deleted nodes in the logical incremental difference graph. The business operations corresponding to these nodes no longer exist in the new version, inevitably affecting existing test cases related to them. The second part comprises old version logical nodes connected to all directed logical edges marked as deleted edges in the logical incremental difference graph. While the business operations corresponding to these nodes still exist in the new version, their dependencies with other business operations have changed, potentially affecting the execution paths of existing test cases related to them. These two parts of old version logical nodes are merged and deduplicated to form the directly affected regions.

[0070] The indirect impact region is determined using breadth-first search (BFS). BFS is a graph traversal algorithm that starts from a specified starting node and visits nodes in the graph in ascending order of distance from the starting node. For each old version logical node in the directly changed region, a BFS is performed in the old version logical flow graph starting from that old version logical node. During the traversal, the algorithm expands both forward and backward along directed logical edges, visiting other old version logical nodes that have direct or indirect dependencies on the starting node. The traversal depth is limited by a propagation depth threshold, which represents the maximum graph distance that can be reached from the starting node. The graph distance refers to the minimum number of directed logical edges required to reach the target node from the starting node. The propagation depth threshold is set based on the typical link length of government business processes. Setting the threshold too high will cause the indirect impact region to over-expand and include a large number of nodes that are not actually affected. Setting the threshold too low will cause the indirect impact region to miss nodes that are actually affected. For example, if the propagation depth threshold is set to 3, for each old version logical node in the directly changed region, the BFS will visit all old version logical nodes whose graph distance is no more than 3. The old version logical nodes visited by the breadth-first traversal of all old version logical nodes in the directly affected area are aggregated and deduplicated to form the indirectly affected area.

[0071] The overall impact area is obtained by taking the union of the directly changed area and the indirectly affected area. The overall impact area represents the entire logical scope that this requirement change may affect in the old version's logical flow diagram. All nodes in the overall impact area are old version logical nodes from the old version's logical node set. Determining the overall impact area provides a filtering basis for the subsequent evolution of existing use case paths. If an existing use case path passes through a node in the overall impact area, it needs to be evolved and repaired; if it does not pass through a node in the overall impact area, it can be directly retained without modification. This filtering mechanism avoids the computational overhead of performing evolution and repair on all existing use cases. Step S13 uses change propagation analysis to extend the impact of the version change from the direct change point to the indirectly related area, expanding the identification of the impact scope from local change points to a systemic impact domain. The identification of the directly changed area ensures that the deleted business operations and the dependencies of the change are accurately identified. The determination of the indirectly affected area captures the propagation effect of the change along the dependency link through breadth-first traversal. The merging of the overall impact area forms a complete change impact boundary.

[0072] The new version logic flow graph in step S10 serves as the target graph structure for the geometric deformation of the use case path in step S20. Nodes on the old version use case path are moved from the old version logic flow graph to the new version logic flow graph via traction vectors, forming the deformed use case path. The node correspondence table serves as the mapping basis for calculating the single-point traction vector in step S20. The corresponding node pairs recorded in the node correspondence table indicate the target position of each old version logic node in the new version logic flow graph. The set of old version unique nodes serves as the basis for identifying old version unique nodes and judging dangling nodes in step S20. Old version logic nodes belonging to the set of old version unique nodes have been deleted in the new version, and their single-point traction vector calculation requires special handling. The set of newly added nodes in the new version serves as the source of candidate nodes for path expansion and supplementation in step S20. The deformed use case path forms the final evolution path by inserting relevant newly added nodes in the new version. The overall influence area serves as the screening basis for identifying affected paths in step S20. Old version use case paths in the existing use case path set that intersect with the overall influence area are identified as affected paths and enter the subsequent traction repair process. Without step S10, the existing test case path mapping in subsequent step S20 will lack a structured graph foundation, and the test step sequence will not be able to be converted into directed paths on the old version's logic flow graph; the calculation of single-point traction vectors will lack the basis for node correspondence, making it impossible to determine the target position of old version logic nodes in the new version's logic flow graph; and the identification of affected paths will lack the basis for the scope of impact, making it impossible to distinguish between test cases that need to be repaired and those that can be directly retained. Step S10, as the basic information preparation step of the entire method, provides complete topology change information, node mapping relationships, and scope of impact for the subsequent evolution of existing test case paths and verification of the rationality of the evolution.

[0073] Step S10 utilizes logical flow graph topology comparison technology to elevate requirement changes from character differences at the text level to structural differences at the logical topology level. This improves the accuracy of change identification, enabling the capture of process structure changes, dependency adjustments, and business constraint modifications that traditional text comparison techniques cannot identify. Through graph isomorphism matching technology, the correspondence between the old and new versions of the logical flow graph is made explicit, making the classification of retained, deleted, and added nodes, as well as retained, deleted, and added edges, clear and traceable, providing accurate topology change information for subsequent incremental evolution. Through change propagation analysis technology, the impact of version changes is extended from direct change points along dependency links to indirectly related areas, ensuring that the identification of the impact range is neither overlooked nor over-expanded. The propagation depth threshold is set to strike a balance between identification completeness and computational efficiency. The logic flow diagram of the old version, the logic flow diagram of the new version, the logic increment difference diagram, the node correspondence table, the set of nodes unique to the old version, the set of nodes added in the new version, and the overall impact area output in step S10 form a complete information system of incremental requirement differences. This provides a structured and computable analytical basis for the subsequent evolution and repair of existing test cases, avoiding the problem of the complete abandonment of existing test cases due to the lack or ambiguity of requirement change information in traditional methods. This transforms the evolution and repair of test assets from extensive full regeneration to refined incremental adaptive adjustment.

[0074] Step S20: Obtain the existing test case set, map each existing test case in the existing test case set to the old version logic flow graph to form an existing test case path set, identify the affected path set from the existing test case path set according to the overall impact area, perform path geometric deformation on each old version test case path in the affected path set, and expand the deformed test case path to generate the final evolution path.

[0075] Further, step S20 includes:

[0076] Step S21: Obtain the existing test case set, extract the test step sequence from each existing test case in the existing test case set, perform semantic matching between each test step in the test step sequence and the old version logical node set to determine the mapping node, connect all mapping nodes according to the execution order of the test steps to form the old version test case path, and summarize all the old version test case paths to form the existing test case path set.

[0077] Specifically, the acquisition of the existing test case set is achieved through the government software testing management system. This set contains all test cases designed and executed for the old version's requirements document set. Each existing test case is stored in a structured format, including fields such as test case identifier, test case name, preconditions, test step sequence, expected result, and actual result. Existing test cases are test assets designed by testers based on their understanding of the old version's requirements and business experience. They embody the testers' deep understanding of business processes and expert judgment of boundary conditions. This expert experience is embedded in the design logic of the test steps as tacit knowledge. The test step sequence is extracted from the test step field of the existing test case. The test step sequence is an ordered list, where each test step corresponds to a specific operation in the test execution process. The order of the test steps reflects the temporal flow of test execution. For example, an existing test case's test step sequence contains five test steps: logging into the system, filling out an application form, submitting for approval, approval, and public announcement. These five test steps are arranged in execution order to form the test step sequence.

[0078] The semantic matching between test steps and the old version logical node set employs the same vectorized matching method as the semantic similarity calculation in step S12. For each test step in the test step sequence, the text description of the test step is converted into a semantic vector representation. All old version logical nodes in the old version logical node set are traversed, and the cosine similarity between the semantic vector of the test step and the node semantic vector of each old version logical node is calculated. The old version logical node with the highest cosine similarity is identified as the mapping node of the test step on the old version logical flow graph. Determining the mapping node transforms the test step from a natural language description into node location on the logical flow graph, and transforms the test case from text form into a graph structure form. For example, the semantic matching of the test step "Submit for Approval" with "Approval Form + Submission + Complete Application Materials" in the old version logical node set yields a cosine similarity of 0.86, which is higher than the similarity with other old version logical nodes. Therefore, "Approval Form + Submission + Complete Application Materials" is determined as the mapping node for the test step "Submit for Approval".

[0079] The old version test case path is formed based on the mapping nodes of all test steps in the test step sequence. All mapping nodes are connected sequentially according to the execution order of the test steps in the sequence, forming a directed path from the starting mapping node to the ending mapping node. The old version test case path is a sub-path on the old version logic flow graph. The starting point of the old version test case path is the mapping node of the first test step in the test step sequence, and the ending point is the mapping node of the last test step in the test step sequence. The intermediate nodes traversed by the old version test case path are the mapping nodes of the remaining test steps in the test step sequence. Edges in the old version test case path connect adjacent mapping nodes. If there is a direct directed logical edge between adjacent mapping nodes in the old version logic flow graph, the old version test case path directly uses the directed logical edge in the old version logic flow graph. If there is no direct directed logical edge between adjacent mapping nodes in the old version logic flow graph but an indirect path exists, the old version test case path uses all directed logical edges in the indirect path. The old version test case paths of all existing test cases in the existing test case set are summarized to form the existing test case path set. Each old version test case path in the existing test case path set is represented as a directed path on the old version logical flow graph.

[0080] Step S21 transforms existing test cases from textual descriptions in natural language into directed path representations on the old version's logic flow graph, establishing a topological mapping relationship between existing test cases and the logic flow graph. Traditional existing test case management only stores test steps in text form, failing to establish a connection with the logical structure of requirements. When requirements change, it's difficult to determine whether existing test cases are affected. By mapping test steps to old version logic nodes, the old version test case path becomes a subgraph of the old version's logic flow graph, making the coverage relationship between existing test cases and requirement logic explicit. The old version logic nodes traversed by the old version test case path are the business logic units covered by the existing test cases, providing a topological basis for subsequent determination of whether existing test cases are affected by requirement changes. The use of semantic matching methods ensures that the correspondence between test steps and old version logic nodes does not rely on precise text matching. It can identify correspondences that differ in expression but are semantically equivalent, avoiding mapping failures caused by differences in tester coding styles.

[0081] Step S22: Determine whether the path node set of each old version use case path in the existing use case path set intersects with the overall affected area. Mark the old version use case paths that intersect as affected paths and add them to the affected path set. Calculate the change crossover ratio of the affected paths. Mark the old version use case paths that do not intersect as unaffected paths and add them to the unaffected path set.

[0082] The path node set is extracted from the old version use case paths. The path node set contains all old version logical nodes traversed by the old version use case paths. The path node set is stored as a set, with duplicate nodes removed. The intersection of the path node set and the overall affected area is determined using set intersection. If the intersection is not empty, it indicates that the old version use case path traversed the logical area affected by the requirement change, and the old version use case path needs evolution and repair. If the intersection is empty, it indicates that the old version use case path did not traverse the logical area affected by the requirement change, and the old version use case path can be directly retained without modification. Affected paths are marked by adding old version use case paths whose path node sets intersect with the overall affected area to the affected path set. All old version use case paths in the affected path set must enter the subsequent traction field-driven deformation process. Unaffected paths are marked by adding old version use case paths whose path node sets do not intersect with the overall affected area to the unaffected path set. All old version use case paths in the unaffected path set can continue to be used without any modification.

[0083] The calculation of the change crossover ratio quantifies the degree of correlation between the affected path and the requirement change. The change crossover node set is the intersection of the path node set and the overall affected area. The number of nodes in the change crossover node set indicates how many of the old version logical nodes traversed by the old version use case path are within the scope of the requirement change's impact. The change crossover ratio equals the number of nodes in the change crossover node set divided by the total number of nodes in the path node set. The change crossover ratio ranges from 0 to 1. A higher change crossover ratio indicates a deeper impact of the requirement change on the old version use case path, while a lower change crossover ratio indicates a shallower impact. For example, if the path node set of an old version use case path contains 6 old version logical nodes, of which 3 old version logical nodes belong to the overall affected area, and the change crossover node set contains 3 nodes, the change crossover ratio equals 3 divided by 6, which is 0.5, indicating that half of the nodes in the old version use case path are affected by the requirement change. The change crossover ratio will be used as an auxiliary indicator for determining the use case evolution status in step S30.

[0084] Step S22 divides the existing test case path set into two subsets—an affected path set and an unaffected path set—through path coverage analysis. This ensures that subsequent remediation operations are only performed on existing test cases genuinely affected by the requirement change, avoiding the computational overhead of performing evolutionary remediation on all existing test cases. The intersection determination of the path node set and the overall impact area utilizes the overall impact area calculated in step S10. The overall impact area accurately defines the scope of the requirement change's influence on the old version's logic flow diagram, ensuring that the identification of affected paths is neither missed nor false positives. The calculation of the change crossover ratio provides a quantitative indicator for subsequently determining whether existing test cases can be adapted to the new version's requirements through evolutionary remediation. Existing test cases with an excessively high change crossover ratio may need to be discarded and rebuilt rather than undergoing evolutionary remediation. The direct retention of the unaffected path set minimizes the impact of the requirement change on existing test assets. Existing test cases unaffected by the change can continue to be used without any processing, maximizing the preservation of the expert experience accumulated by testers.

[0085] Step S23: For each old version logical node on each old version use case path in the affected path set, calculate the single-point traction vector according to the node correspondence table, determine the continuity of the path segment based on the single-point traction vectors of adjacent old version logical nodes, and mark the path segment as a possible broken path segment if the single-point traction vectors of the old version logical nodes at both ends of the path segment are opposite in direction or the difference in magnitude exceeds the preset traction difference threshold. Calculate the continuity repair vector, superimpose the single-point traction vector and the continuity repair vector to obtain the final traction force vector, and integrate all the final traction force vectors to form the overall traction force field.

[0086] The calculation of the single-point traction vector is performed on each old version logical node on each old version use case path in the affected path set. The single-point traction vector represents the direction and distance that the old version logical node moves from the old version logical flow graph to the new version logical flow graph. The calculation of a single-point traction vector requires distinguishing between three states of old version logical nodes: The first state is that the old version logical node exists as part of a corresponding node pair in the node correspondence table, indicating that the old version logical node has a semantically corresponding new version logical node in the new version logical flow graph; The second state is that the old version logical node belongs to the old version-unique node set and its predecessor node set or successor node set contains an old version logical node that exists as part of a corresponding node pair in the node correspondence table, indicating that the old version logical node has been deleted in the new version but has anchor points around it that can be tractioned; The third state is that the old version logical node belongs to the old version-unique node set and neither its predecessor node set nor its successor node set contains an old version logical node that exists as part of a corresponding node pair in the node correspondence table, indicating that the old version logical node has been deleted in the new version and has no anchor points around it that can be tractioned. Such old version logical nodes are marked as dangling nodes.

[0087] For the old version logical node in the first state, the corresponding new version logical node is obtained from the node correspondence table. The direction of the single-point traction vector points from the topological position of the old version logical node in the old version logical flow graph to the topological position of the new version logical node in the new version logical flow graph. The magnitude of the single-point traction vector is equal to the topological coordinate distance between the two topological positions. The topological position is represented by the topological coordinates of the node in the logical flow graph. The topological coordinates are calculated based on the node's in-degree, out-degree, path level, and other topological features. The topological coordinates are represented as numerical vectors. Nodes in the old version logical flow graph and nodes in the new version logical flow graph use the same topological feature dimensions and the same calculation rules to generate topological coordinates, allowing the topological positions of nodes in different logical flow graphs to be compared in a unified coordinate space. The topological coordinate distance is calculated using the Euclidean distance between two topological coordinate vectors. The Euclidean distance measures the absolute positional difference between the two vectors in the coordinate space. For example, the old version logical node "Approval Form Plus Review" corresponds to the new version logical node "Approval Document Plus Review" in the node correspondence table. The old version logical node "Approval Form Plus Review" is located at the second node of the third level in the old version logical flow diagram. The new version logical node "Approval Document Plus Review" is located at the first node of the fourth level in the new version logical flow diagram. The direction of the single-point traction vector points from the second node of the third level to the first node of the fourth level. The magnitude of the single-point traction vector is equal to the topological coordinate distance between the two positions.

[0088] For the old version logical nodes in the second state, since they have been deleted in the new version, it is necessary to find a traction anchor point from their predecessor and successor node sets. The predecessor node set contains all old version logical nodes in the old version logical flow graph that are directly pointed to by the old version logical nodes through directed logical edges. The successor node set contains all old version logical nodes in the old version logical flow graph that are directly pointed to by the old version logical nodes through directed logical edges. For each old version logical node in the predecessor and successor node sets, it is determined whether it exists as part of a corresponding node pair in the node correspondence table. If it exists, the old version logical node is selected as a candidate anchor point. From all candidate anchor points, the candidate anchor point with the closest distance to the deleted old version logical node is selected as the traction anchor point. The direction of the single-point traction vector points to the direction of the topological position of the new version logical node corresponding to the traction anchor point in the node correspondence table in the new version logical flow graph. The magnitude of the single-point traction vector is equal to the topological coordinate distance between the topological coordinates of the deleted old version logical node and the topological coordinates of the new version logical node corresponding to the traction anchor point. The old version logical nodes in the second state no longer exist in the new version and will be deleted during subsequent path deformation. Their single-point traction vectors are used for path segment continuity judgment and continuity repair vector calculation. For the suspended nodes in the third state, since there are no surrounding anchor points for traction, the single-point traction vector is set to zero, and the suspended nodes will be deleted during subsequent path deformation. The old version logical nodes in both the second and third states belong to the node set unique to the old version and will be deleted and marked as path breakpoints during subsequent path deformation.

[0089] The single-point traction vectors of all old version logical nodes on the old version use case path are aggregated to form a node traction vector set. This set is a mapping set where old version logical nodes are keys and their corresponding single-point traction vectors are values. The node traction vector set is used for subsequent path segment continuity determination. A path segment is defined as the original directed logical edge between two adjacent old version logical nodes on the old version use case path. A path segment is the basic building block of the old version use case path, which consists of several interconnected path segments. The continuity determination of a path segment is based on the single-point traction vectors of the old version logical nodes at both ends of the path segment in the node traction vector set. The node traction vector set contains the single-point traction vectors of all old version logical nodes on the old version use case path. The principle of path segment continuity judgment is as follows: if the single-point traction vectors of the old version logical nodes at both ends of the path segment have the same direction and similar magnitude, then the two nodes will move similar distances in the same direction during the traction process, and the path segment can still remain continuous after traction; if the single-point traction vectors of the old version logical nodes at both ends of the path segment have opposite directions or large differences in magnitude, then the two nodes will move in different directions or move significantly different distances during the traction process, and the path segment may break after traction.

[0090] The traction difference threshold is set to quantify the standard for judging the continuity of path segments. The threshold is determined based on the typical topological distance variation range between adjacent logical nodes in government business processes, obtained through statistical analysis of historical version change data. For example, the traction difference threshold is set as the ratio of the absolute value of the difference between the magnitudes of the traction vectors at both ends of a path segment to the larger of the two values ​​does not exceed 0.5. If the ratio exceeds 0.5, the magnitude difference is considered to exceed the traction difference threshold. The determination of opposite directions uses the angle between two single-point traction vectors. If the angle exceeds a preset direction difference threshold, the directions are considered opposite. For example, the direction difference threshold is set to 90 degrees; if the angle between two single-point traction vectors exceeds 90 degrees, the directions are considered opposite. Path segments identified as potentially broken are marked as potentially broken path segments and will be given special attention during subsequent path deformation processes.

[0091] The calculation of the continuity repair vector is used to maintain the continuity of the path segment during the traction process, avoiding unnecessary breakage due to excessive differences in the traction direction or magnitude between the two end nodes. For each path segment marked as potentially breakable, let the single-point traction vector of the starting end node be the starting traction vector and the single-point traction vector of the ending end node be the ending traction vector. The difference between the traction vectors is calculated as the vector difference between the starting and ending traction vectors. The direction of the continuity repair vector obtained by the starting end node from the path segment is opposite to the direction of the traction vector difference, and its magnitude is equal to the magnitude of the traction vector difference multiplied by the continuity repair coefficient. The direction of the continuity repair vector obtained by the ending end node from the path segment is the same as the direction of the traction vector difference, and its magnitude is equal to the magnitude of the traction vector difference multiplied by the continuity repair coefficient. The design logic of the continuity repair vector is: by applying a repair force to the starting end node that moves towards the ending end traction direction, and applying a repair force to the ending end node that moves towards the starting end traction direction, the two end nodes move closer to each other during movement, reducing the possibility of path segment breakage. The continuity repair coefficient ranges from 0 to 1. Setting the continuity repair coefficient requires balancing the relationship between maintaining path continuity and node displacement accuracy. The coefficient is determined based on statistical analysis of path continuity and node displacement accuracy in historical version change data. An excessively large continuity repair coefficient can cause nodes to deviate from their correct target positions, while an excessively small coefficient cannot effectively suppress path breaks. When an old version logical node is the endpoint of multiple potentially broken path segments, it obtains a continuity repair vector from each of these segments. All continuity repair vectors are then summed to obtain the composite continuity repair vector for the old version logical node.

[0092] The final traction vector is calculated by superimposing the single-point traction vector and the continuity repair vector using vector addition. The final traction vector equals the sum of the single-point traction vector and the continuity repair vector. For older version logical nodes that do not belong to any endpoint of a possible broken path segment, the continuity repair vector is zero, and the final traction vector equals the single-point traction vector. For older version logical nodes that belong to endpoints of a possible broken path segment, the continuity repair vector is the continuous repair vector obtained from one possible broken path segment to which the older version logical node belongs, or the composite continuous repair vector obtained by vector accumulation from the continuous repair vectors obtained from multiple possible broken path segments to which the node belongs. The final traction vector is the result of superimposing the single-point traction vector and the continuous repair vector. The superimposed final traction vector retains the trend of moving towards the target position and includes a correction component to maintain path continuity. The formation of the overall traction field integrates the final traction vectors of all old version logic nodes on the old version use case path into a unified vector field. The overall traction field describes the displacement direction and displacement amount of each node in the old version use case path during the transformation from the old version logic flow graph to the new version logic flow graph.

[0093] Step S23 transforms the evolution of existing use case paths from a qualitative description to a quantitative calculation through traction vector calculation, giving path deformation a clear mathematical expression and operability. The calculation of single-point traction vectors utilizes the node correspondence table established in step S10. This table provides a mapping relationship between old and new version logical nodes, ensuring the target position of the traction vector is determined based on evidence. Differentiated processing of three states ensures that the calculation of single-point traction vectors covers all possible scenarios encountered by old version logical nodes. Different calculation strategies are used for retained nodes, tractable deleted nodes, and suspended nodes, ensuring the completeness of traction calculations. The introduction of path segment continuity judgment and continuity repair vectors protects the integrity of the path during deformation, avoiding path fragmentation caused by differences in the traction direction of local nodes. The construction of the overall traction force field integrates the dispersed node-level traction vectors into a path-level deformation scheme, allowing subsequent path deformation to be executed within a unified force field framework.

[0094] Step S24: Based on the final traction force vector of each old version logic node in the overall traction force field, move the old version logic node from its original position in the old version logic flow graph to its target position in the new version logic flow graph. Delete the old version logic nodes marked as suspended nodes from the path and mark the path breakpoints at their original positions. For path segments marked as potentially broken path segments, determine whether there are directed logical edges at both ends of the target positions in the new version logic flow graph. If there are no directed logical edges, mark the path breakpoints at the path segment positions. Summarize all path breakpoints to form a breakpoint set. Re-establish connections in the new version logic flow graph based on the original path segment connection relationships to form the deformed use case path.

[0095] The breakpoint set is initialized as an empty set. This set records all path breakpoints generated during the transformation of the old version use case path. A path breakpoint indicates a position where the old version use case path cannot maintain continuity after transformation. The movement of old version logic nodes is executed based on the corresponding final traction force vector in the overall traction field. The target position is determined according to the following rules: If an old version logic node exists as part of a corresponding node pair in the node correspondence table, the target position is the position of the new version logic node contained in the corresponding node pair in the new version logic flow graph. After the movement, the old version logic node is replaced by the new version logic node. If an old version logic node belongs to a unique set of old version nodes, it is deleted from the transformed path. Simultaneously, a path breakpoint is marked at the original position of the old version logic node and added to the breakpoint set. The path breakpoint marking records the position information of the deleted node in the original old version use case path, used for subsequent energy loss calculations. Old version logical nodes belonging to the old version-unique node set include old version logical nodes marked as dangling nodes and old version logical nodes that are not marked as dangling nodes but belong to the old version-unique node set. Both types of old version logical nodes no longer exist in the new version and must be deleted from the transformed path and the path breakpoint must be marked.

[0096] The handling of potentially broken path segments is performed after all old version logical nodes have been moved. For each path segment marked as potentially broken, it is first determined whether the old version logical nodes at both ends of the path segment do not belong to the set of old version unique nodes. If the old version logical node at one end of the path segment belongs to the set of old version unique nodes, then the node at that end has been deleted and marked as a path break point in the previous steps, and the path segment has been broken due to the deletion of the endpoint, so there is no need to perform connectivity judgment again. If the old version logical nodes at both ends of the path segment do not belong to the set of old version unique nodes, it is determined whether there is a directed logical edge between the two new version logical nodes corresponding to the old version logical nodes at both ends of the path segment after they have moved to their respective target positions. If there is a directed logical edge between two new version logical nodes in the new version logical flow graph, the path segment remains continuous after transformation and no breakpoint needs to be marked. If there is no directed logical edge between two new version logical nodes in the new version logical flow graph, the path segment breaks after transformation, and a path breakpoint is marked at the location of the path segment. The original old version logical node corresponding to this path breakpoint is the starting old version logical node of the path segment in the original old version use case path, and the path breakpoint is added to the breakpoint set. The determination of path segment breakage is based on the topology of the new version logical flow graph. A break is only determined when there is indeed no direct connection between the two target nodes in the new version logical flow graph. This determination method ensures the accuracy of breakpoint marking.

[0097] The formation of the transformed use case path is executed after all old version logical nodes have been moved to their respective target positions and all breakpoints have been marked. Based on the connection relationships of the path segments in the original old version use case path, connections between corresponding new version logical nodes are re-established in the new version logical flow graph. For unbroken path segments, connections are directly established using the directed logical edges between the corresponding two new version logical nodes in the new version logical flow graph; for broken path segments, the connection relationship is interrupted, and the breakpoint is marked by the path breakpoints in the breakpoint set. The transformed use case path is a path on the new version logical flow graph, and the nodes traversed by the transformed use case path are new version logical nodes. The topology of the transformed use case path reflects the form of the original old version use case path under the new version logical structure. The breakpoint set is stored as an associated attribute of the transformed use case path. The breakpoint set and the transformed use case path together constitute the complete result of path transformation. The transformed use case path describes the main node structure and connectable parts after path transformation, while the breakpoint set describes the discontinuous positions and structural loss information generated during path transformation. Each path breakpoint in the breakpoint set records the location index of the breakpoint in the modified use case path and the corresponding original old version logical node information. The location index indicates which two adjacent new version logical nodes the breakpoint is located between in the modified use case path node sequence. The original old version logical node information is used to trace the cause of the breakpoint and calculate the contribution value of the location loss. The modified use case path inherits the test intent of the original old version use case path. The test intent refers to the business logic and business scenarios that the existing test cases are designed to verify. The test intent of the modified use case path is inherited by retaining the correspondence between the start and end nodes and the main path structure of the original old version use case path. The breakpoint set will be passed to subsequent steps along with the modified use case path. In step S25, it is inherited by the final evolution path. In step S31, it is used to calculate the structural energy loss. In step S33, it is used to identify key breakpoints and generate patch use cases.

[0098] Step S24 transforms the overall traction field calculated in step S23 into an actual path deformation operation, converting the old version use case path from its form on the old version logic flow graph to its form on the new version logic flow graph. The deletion of nodes unique to the old version and the marking of breakpoints explicitly record irreparable structural losses during path deformation, and the set of breakpoints provides a quantitative basis for subsequent energy loss assessment. Secondary verification of potentially broken path segments makes breakage judgment more accurate; only path segments that are truly non-connected in the new version logic flow graph are judged as broken, avoiding misjudgments due solely to differences in traction vectors. The formation of the deformed use case path completes the structural adaptation of existing use cases from the old version to the new version. The deformed use case path retains the testing intent of the original old version use case path while adapting to the topological structure of the new version logic flow graph.

[0099] Step S25: Traverse the set of newly added nodes in the new version, determine the correlation between each newly added node in the new version and the modified use case path, insert the relevant newly added nodes in the new version as extension nodes into the modified use case path, and generate the final evolution path. The final evolution path inherits the set of breakpoints of the modified use case path.

[0100] The determination of the relevance between newly added nodes in the new version and the modified test case path is performed from two dimensions: connection dimension and semantic dimension. The connection dimension determination iterates through each newly added node in the set of newly added nodes in the new version, checking if there is a direct directed logical edge connection between the newly added node and any new version logical node traversed by the modified test case path. A direct directed logical edge connection means that there is a directed logical edge in the new version logic flow graph between the newly added node and a certain new version logical node in the modified test case path. The direction of the directed logical edge can be from the newly added node to a new version logical node in the modified test case path, or vice versa. The semantic dimension determination is performed after the connection dimension determination passes, checking whether the business semantics of the newly added node in the new version is related to the test intent of the modified test case path. The business semantics of the newly added node in the new version are extracted from the business entities, business actions, and business conditions contained in the newly added node. The test intent of the modified test case path is obtained by comprehensively analyzing the business semantics of all new version logical nodes traversed by the modified test case path. The semantic relevance is determined by semantic similarity calculation. The business semantic vector of the newly added node in the new version is compared with the test intent vector of the transformed use case path by cosine similarity calculation. If the similarity exceeds the preset relevance threshold, it is determined to be relevant.

[0101] The insertion of extended nodes is performed after both the connectivity and semantic dimensions are deemed relevant. The newly added node in the new version is inserted as an extended node into the transformed use case path. The insertion position is determined based on the direction of the directed logical edge between the newly added node and an existing new version logical node in the transformed use case path: if a directed logical edge points from a new version logical node in the transformed use case path to the newly added node, the newly added node is inserted after that new version logical node; if a directed logical edge points from a newly added node to another new version logical node in the transformed use case path, the newly added node is inserted before that new version logical node. Determining the insertion position ensures that the path after insertion maintains directed connectivity, and the inserted extended node is connected to the preceding and following nodes via directed logical edges in the new version logical flow graph. For example, the modified use case path passes through the node sequence of public document plus release, result announcement plus generation, and archive record plus archiving. The new version's newly added node set includes the new version's newly added node objection handling plus acceptance. There is a directed logical edge between objection handling plus acceptance and public document plus release, pointing from public document plus release to objection handling plus acceptance. The business semantics of objection handling plus acceptance are related to the test intent of the modified use case path. Therefore, objection handling plus acceptance is inserted as an extended node after public document plus release. The node sequence after insertion is public document plus release, objection handling plus acceptance, result announcement plus generation, and archive record plus archiving.

[0102] The generation of the final evolution path is performed after the path expansion and supplementation are completed, defining the expanded use case path as the final evolution path. The final evolution path is the complete path on the new version's logical flow graph, containing all nodes of the transformed use case path and the inserted expansion nodes. The final evolution path inherits the breakpoint set of the transformed use case path. The path breakpoint position information recorded in the breakpoint set needs to be updated after the insertion of expansion nodes to reflect the impact of expansion node insertion on the path structure. The position update rules are as follows: if the insertion position of an expansion node is before the position of a path breakpoint in the transformed use case path, then the position number of that path breakpoint in the final evolution path is shifted one position to the right; if the insertion position of an expansion node is after or at the same position as a path breakpoint in the transformed use case path, then the position number of that path breakpoint remains unchanged; when multiple expansion nodes exist, the position updates are performed on all path breakpoints in the breakpoint set sequentially according to the insertion order of the expansion nodes in the final evolution path. The final evolution path will undergo an energy loss assessment in step S30 to determine the rationality of the evolution and the evolution status of the use case.

[0103] Step S25 expands the path to ensure the final evolution path covers the new business logic added in the new version requirements, avoiding the defect where the modified use case path only covers the business logic retained in the old version and omits the new business logic. The set of new nodes in the new version is generated by graph isomorphism matching in step S10, containing all new business operations in the new version requirements. By inserting relevant new nodes into the modified use case path, the final evolution path achieves coverage expansion of the new business logic. Dual judgment of connection and semantic dimensions ensures that the inserted extended nodes are both topologically adjacent to the modified use case path and semantically related, avoiding the misinsertion of irrelevant nodes. The insertion position is determined based on the direction of the directed logical edge, ensuring that the extended path maintains directed connectivity and that the final evolution path is a valid execution path in the new version's logic flow graph. The inheritance of the breakpoint set ensures that the final evolution path carries complete path integrity marking information, providing a quantitative basis for structural loss for the energy loss assessment in step S30.

[0104] Step S20 uses traction vector-driven path geometry deformation technology to transform existing test cases from their form on the old version's logic flow graph to their form on the new version's logic flow graph. This allows existing test cases to retain their original testing intent while adapting to the new version's requirement structure. Traditional methods for handling existing test cases employ a full-scale discard strategy when requirements change, treating existing test cases as one-time assets bound to the old version. All test cases are regenerated after the new version goes live, resulting in the loss of expert experience accumulated by testers over a long period. By mapping existing test cases to directed paths on the old version's logic flow graph, the testing intent of existing test cases is explicitly expressed as the start and end nodes and intermediate nodes of the path. The correspondence between start and end nodes and the main path structure are preserved during path deformation, allowing the testing intent to continue to be inherited after evolution. The calculation of the single-point traction vector utilizes the mapping relationship between old and new nodes provided by the node correspondence table, giving the path deformation a clear target direction. The movement direction and distance of each old version logic node are based on data, avoiding deviations in testing intent caused by blind deformation. The introduction of path segment continuity judgment and continuity repair vectors protects the integrity of the path during deformation, avoiding path fragmentation caused by differences in local node traction, and ensuring that the deformed use case path remains as complete and executable as possible. Identification and deletion of nodes unique to the old version removes business logic not present in the new version from the path, and marking path breakpoints explicitly records structural losses, providing a quantitative basis for subsequent energy loss assessment. The insertion of new nodes in the new version ensures that the final evolution path covers the new business logic added in the new version's requirements. The evolved use cases not only retain the original testing intent but also expand the coverage of the new business. The distinction between affected and unaffected paths allows for precise deployment of evolution repair operations. Existing use cases unaffected by changes can continue to be used without any processing, and the computational cost of evolution repair matches the actual scope of the requirement change. The calculation of the change crossover ratio provides a quantitative indicator for subsequent judgment of the evolution's rationality. Existing use cases with an excessively high change crossover ratio may be too drastic to be adapted through evolution repair and need to be discarded and rebuilt.

[0105] Step S30: Calculate the structural energy loss and functional energy loss of the final evolution path to obtain the comprehensive energy loss. Determine the use case evolution status of the final evolution path based on the comprehensive energy loss and the change crossover ratio. Obtain the final test case set based on the use case evolution status and establish a use case evolution genealogy table.

[0106] Further, step S30 includes:

[0107] Step S31: Calculate the structural energy loss based on the set of breakpoints inherited from the final evolution path, extract all new version logical nodes traversed by the final evolution path to form the evolved node set, calculate the evolved semantic center vector of the evolved node set, extract all old version logical nodes traversed by the original old version use case path to form the original node set, calculate the original semantic center vector of the original node set, calculate the vector distance between the evolved semantic center vector and the original semantic center vector as the semantic drift distance, and calculate the functional energy loss based on the semantic drift distance;

[0108] The structural energy loss is calculated as follows: For each path breakpoint in the breakpoint set, determine whether the original old version logic node corresponding to the path breakpoint is located in the starting segment, ending segment, or middle segment of the original old version use case path to determine the location type. For path breakpoints located in the middle segment, further determine whether the path segments on both sides of the path breakpoint can be bypassed and connected through other paths in the new version logic flow graph. Mark the path breakpoints that can be bypassed and connected as bypassable breakpoints, and mark the path breakpoints that cannot be bypassed and connected as non-bypassable breakpoints. Determine the location loss contribution value of each path breakpoint based on the location type and bypassability. Accumulate the location loss contribution values ​​of all path breakpoints in the breakpoint set to obtain the structural energy loss.

[0109] Specifically, the calculation of structural energy loss is based on the set of breakpoints inherited by the final evolution path generated in step S20. The set of breakpoints records all path breakpoints generated during the transformation of the old version use case path. Path breakpoints are position markers that cannot maintain continuity during the transformation of the old version use case path from the old version logic flow graph to the new version logic flow graph. Path breakpoints arise from two scenarios: the first scenario is that the old version logic node belongs to the old version-unique node set and is deleted from the transformed path. The position of the old version logic node belonging to the old version-unique node set in the original old version use case path forms a path breakpoint. The second scenario is that after the old version logic nodes at both ends of the path segment marked as a potentially broken path segment move to their respective target positions, there is no directed logical edge between the two corresponding new version logic nodes in the new version logic flow graph, and the position of the path segment forms a path breakpoint. The original old version logical node refers to the old version logical node itself that was deleted during the path deformation process because it belonged to the old version unique node set, or the old version logical node at the beginning of the broken path segment in the original old version use case path when a break point is generated due to the break point. The information of the original old version logical node is recorded when the break point is marked, and is used to subsequently determine the location type of the break point and calculate the location loss contribution value.

[0110] The location type is determined based on the position segment of the original old version logical nodes within the original old version test case path. The original old version test case path is divided into three location segments according to node position: the start segment, the middle segment, and the end segment. The start segment includes the first few old version logical nodes in the original old version test case path, starting from the beginning. The range of the start segment is determined by the start segment ratio parameter, which represents the proportion of the start segment to the total number of nodes in the original old version test case path. The setting of the start segment ratio parameter is based on the general characteristics of the test case structure. The beginning part of the test case usually corresponds to test environment initialization, precondition preparation, and the entry operation of the function under test. These operations are necessary prerequisites for the execution of the test case. If a break occurs in the start segment, the test case cannot start and execute normally. The terminating segment includes several old version logical nodes in the original old version test case path that lead to the endpoint. The scope of the terminating segment is determined by the terminating segment ratio parameter, which represents the proportion of the terminating segment to the total number of nodes in the original old version test case path. The setting of the terminating segment ratio parameter is based on the general characteristics of the test case structure. The terminating part of the test case usually corresponds to test result verification, expected output checking, and test environment cleanup operations. These operations are necessary components for the test case to complete its verification objective. If a break occurs in the terminating segment, the test case cannot complete the expected result verification. The intermediate segment includes all old version logical nodes in the original old version test case path except for the starting and terminating segments. The intermediate segment corresponds to the main business operation flow of the test case. For example, if the starting segment ratio parameter is set to 0.2 and the terminating segment ratio parameter is set to 0.2, for an original old version test case path containing ten old version logical nodes, the starting segment includes the first and second old version logical nodes, the terminating segment includes the ninth and tenth old version logical nodes, and the intermediate segment includes the third to eighth old version logical nodes.

[0111] The location loss contribution value is determined based on the location type and dodgeability of the path breakpoint. If the original old version logical node corresponding to the path breakpoint is located at the beginning segment of the original old version test case path, the location loss contribution value of the path breakpoint is set as the starting segment loss weight. The starting segment loss weight is greater than the intermediate segment loss weight. The reason for setting the starting segment loss weight is that the break in the starting segment causes the test case to fail to start normally, the break has a global impact, and the test case loses its execution value after evolution. If the original old version logical node corresponding to the path breakpoint is located at the end segment of the original old version test case path, the location loss contribution value of the path breakpoint is set as the end segment loss weight. The end segment loss weight is greater than the intermediate segment loss weight. The reason for setting the end segment loss weight is that the break in the end segment causes the test case to fail to complete the verification operation, the test result cannot be confirmed, and the test case loses its testing value after evolution. For example, the starting segment loss weight is set to 3 times the basic loss unit, and the end segment loss weight is set to 2.5 times the basic loss unit. The basic loss unit is the standard loss amount used for normalization calculation. The basic loss unit is defined as the standardized loss amount generated by a single old version logical node in the original old version use case path during the transformation process. The value of the basic loss unit is equal to 1 divided by the number of nodes in the path node set of the original old version use case path. The design of the basic loss unit normalizes the structural energy loss of paths of different lengths to a unified dimension, making the structural energy loss between the final evolution paths with different numbers of path nodes comparable.

[0112] If the original old version logic node corresponding to the path breakpoint is located in the middle segment of the original old version use case path, the dodgeability of the path breakpoint is further determined. The dodgeability determination is based on the topology of the new version logic flow graph, judging whether the path segments on both sides of the path breakpoint can be bypassed and connected through other paths in the new version logic flow graph. The path segments on both sides of the path breakpoint refer to the predecessor and successor new version logic nodes in the final evolution path. A bypass connection means that there exists a feasible path from the predecessor new version logic node to the successor new version logic node in the new version logic flow graph, and the feasible path can pass through other new version logic nodes not covered by the final evolution path. The bypass connection determination uses a graph reachability analysis algorithm. Starting from the predecessor new version logic node, a depth-first search or breadth-first search is performed in the new version logic flow graph. If the successor new version logic node can be reached during the search, it is determined to be a bypassable connection; otherwise, it is determined to be an inaccessible connection. If a path breakpoint can be bypassed and connected, it is marked as a bypassable breakpoint. The positional loss contribution value of the bypassable breakpoint is set as the bypassable loss weight of the intermediate segment. The bypassable loss weight of the intermediate segment is relatively low because, although a bypassable breakpoint causes the original path to be interrupted, connectivity can be restored through a bypass path in the new version's logic flow graph, and the break's impact is repairable. If a path breakpoint cannot be bypassed and connected, it is marked as an inaccessible breakpoint. The positional loss contribution value of the inaccessible breakpoint is set as the inaccessible loss weight of the intermediate segment. The inaccessible loss weight of the intermediate segment is higher than the bypassable loss weight of the intermediate segment because an inaccessible breakpoint causes the final evolution path to be unconnectable in the new version's logic flow graph. The break's impact cannot be automatically repaired and needs to be supplemented through patch test cases. For example, the bypassable loss weight of the intermediate segment is set to 0.5 times the base loss unit, and the inaccessible loss weight of the intermediate segment is set to 1.5 times the base loss unit. The structural energy loss is calculated by summing the positional loss contributions of all path breakpoints in the breakpoint set. A larger structural energy loss indicates more severe structural breaks in the final evolution path during deformation, resulting in greater loss of path integrity; conversely, a smaller structural energy loss indicates better maintenance of path continuity during deformation, with less loss of path integrity. Structural energy loss quantifies the structural losses caused by node deletion and path segment breaks during path deformation, making path integrity measurable and providing a structural dimension evaluation metric for subsequent use case evolution state determination.

[0113] The calculation of functional energy loss is based on the semantic deviation between the final evolution path and the original old version use case path. The post-evolution node set is extracted from the final evolution path, containing all new version logical nodes traversed by the final evolution path, including new version logical nodes inherited from the transformed use case path and extended nodes inserted in step S25. The original node set is extracted from the original old version use case path corresponding to the final evolution path, containing all old version logical nodes traversed by the original old version use case path. The calculation of the post-evolution semantic center vector involves extracting the business semantic vector for each new version logical node in the post-evolution node set. The extraction method for the business semantic vector is the same as the node semantic vector generation method in step S12. The business entities, business actions, and business conditions contained in the new version logical node are converted into vector representations and concatenated or weighted averaged. The arithmetic mean of the business semantic vectors of all new version logical nodes in the post-evolution node set is taken to obtain the post-evolution semantic center vector. The calculation of the original semantic center vector involves extracting the business semantic vector of each old version logical node in the original node set, and then taking the arithmetic average of the business semantic vectors of all old version logical nodes in the original node set to obtain the original semantic center vector.

[0114] The semantic drift distance is calculated using the Euclidean distance between the evolved semantic center vector and the original semantic center vector. Euclidean distance measures the absolute positional difference between the two vectors in the vector space. A larger semantic drift distance indicates a greater deviation between the business semantics covered by the final evolution path and those covered by the original old version's test case path, resulting in a lower degree of inheritance of test intent. Conversely, a smaller semantic drift distance indicates that the final evolution path better maintains the test intent of the original old version's test case path, resulting in higher consistency of business semantics. The semantic drift threshold is set to determine whether semantic drift exceeds an acceptable range. The semantic drift threshold is determined based on empirical analysis of test case semantic similarity, obtained by statistically analyzing the distribution of semantic center vector distances between semantically identical test cases in historical test case data. The semantic drift threshold is set as the upper boundary value of this distribution. For example, a semantic drift threshold of 0.35 indicates that a semantic drift distance exceeding 0.35 is considered a significant semantic drift.

[0115] The calculation of functional energy loss is based on a comparison between semantic drift distance and semantic drift threshold. If the semantic drift distance does not exceed the semantic drift threshold, the functional energy loss is set as the semantic drift distance multiplied by the functional loss base coefficient. The functional loss base coefficient is used to convert the semantic drift distance into a loss dimension comparable to structural energy loss. If the semantic drift distance exceeds the semantic drift threshold, it is determined that the final evolution path has deviated from the test intent of the original old version use case path. The functional energy loss is then set as the semantic drift distance multiplied by the functional loss base coefficient and then multiplied by the semantic drift amplification constant. The semantic drift amplification constant is greater than 1. The basis for setting the semantic drift amplification constant is that semantic drift exceeding the threshold indicates a fundamental deviation from the test intent. The loss impact of such deviation should be amplified to trigger more stringent processing in subsequent state determinations. For example, the functional loss base coefficient is set to 5 times the base loss unit, and the semantic drift amplification constant is set to 3. When the semantic drift distance is 0.4 and exceeds the semantic drift threshold of 0.35, the functional energy loss is equal to 0.4 multiplied by 5 times the base loss unit and then multiplied by 3.

[0116] Step S31 decomposes the loss during path deformation into two independent dimensions—structural integrity loss and semantic consistency loss—through separate calculations of structural energy loss and functional energy loss. Structural energy loss quantifies the degree of path breakage at the topological level, while functional energy loss quantifies the degree of path drift at the business semantic level. This separate calculation of the two dimensions makes loss assessment more refined, distinguishing between path unavailability due to structural breakage and loss of test intent due to semantic drift—two different types of evolutionary failures. The dual judgment of location type and detourability ensures that the loss contribution value of the breakpoint matches its actual impact. High loss weights for breakpoints at the start and end points reflect the severity of breakages in critical parts of the test case, while low loss weights for detourable breakpoints reflect the mild impact of repairable breakages. The calculation of the semantic center vector aggregates the semantic information of multiple logical nodes covered by the path into a single vector representation, enabling comparison of the overall semantics of the path. The introduction of a semantic drift threshold and an over-threshold amplification mechanism differentiate between minor semantic drift and severe semantic deviation.

[0117] Step S32: Add the structural energy loss and the functional energy loss to obtain the comprehensive energy loss. Determine the use case evolution status of the final evolution path based on the comprehensive energy loss and the change crossover ratio. The use case evolution status includes fully adapted, partially adapted, and incompatible.

[0118] The calculation of comprehensive energy loss is obtained by adding structural energy loss and functional energy loss. Comprehensive energy loss integrates loss information from both structural and functional dimensions to form a comprehensive evaluation index for the evolution quality of the final evolution path. The larger the value of comprehensive energy loss, the worse the evolution quality of the final evolution path, which may indicate severe structural fractures or significant semantic drift. The smaller the value of comprehensive energy loss, the better the evolution quality of the final evolution path, indicating that the path maintains structural integrity and semantic consistency better during deformation.

[0119] The determination of the use case evolution status is based on a comparison between the overall energy loss and a preset loss threshold, and a comparison between the change crossover ratio calculated in step S22 and a preset upper limit of the crossover ratio. The low loss threshold and high loss threshold are used to divide the overall energy loss range. The low loss threshold is set based on the upper bound of the overall energy loss distribution of successfully evolved use cases in historical evolution data, and the high loss threshold is set based on the lower bound of the overall energy loss distribution of failed evolved use cases in historical evolution data. The upper limit of the crossover ratio is used to determine whether the change crossover ratio exceeds an acceptable range. The upper limit of the crossover ratio is set based on empirical analysis of the correlation between existing use cases and requirement changes. An excessively high change crossover ratio indicates that the main part of the existing use cases is within the scope of the change's impact, and even if the overall energy loss is low, it is difficult to guarantee the effectiveness of the evolved use cases. For example, the low loss threshold is set to 10 times the basic loss unit, the high loss threshold is set to 30 times the basic loss unit, and the upper limit of the crossover ratio is set to 0.8.

[0120] If the overall energy loss is less than the low loss threshold and the crossover ratio does not exceed the crossover ratio limit, the use case evolution status of the final evolution path is marked as fully adapted. A fully adapted status means that the existing test cases corresponding to the final evolution path can be successfully adapted to the new version requirements directly through path deformation. Structural breaks and semantic drifts during the deformation process are within acceptable limits, and the evolved test cases can be used without additional processing. If the overall energy loss is greater than or equal to the low loss threshold but less than the high loss threshold and the crossover ratio does not exceed the crossover ratio limit, the use case evolution status of the final evolution path is marked as partially adapted. A partially adapted status means that the existing test cases corresponding to the final evolution path can adapt to the main part of the new version requirements through path deformation, but there are local breaks or drift areas that need to be supplemented with patch test cases. The evolved test cases need to be used in conjunction with patch test cases to fully cover the test scenario. If the overall energy loss is greater than or equal to the high loss threshold, or the crossover ratio exceeds the crossover ratio limit, the use case evolution status of the final evolution path is marked as incompatible. An incompatible state indicates that the existing test cases corresponding to the final evolution path differ too much from the requirements of the new version. The losses during the transformation process have exceeded the scope of repair and cannot be adapted through repair operations. It is necessary to discard the existing test cases and regenerate replacement test cases.

[0121] Step S32, by comparing the overall energy loss with the loss threshold and the change crossover ratio with the upper limit of the crossover ratio, divides the final evolution path into three use case evolution states: fully adapted, partially adapted, and incompatible. This division differentiates subsequent processing strategies: a fully adapted final evolution path is directly converted into an evolved use case; a partially adapted final evolution path requires the generation of patch use cases to supplement it; and an incompatible final evolution path requires the regeneration of alternative use cases. The dual judgment of overall energy loss and change crossover ratio makes the evolution state determination more robust. Overall energy loss assesses evolution quality from the perspective of evolution results, while change crossover ratio assesses evolution difficulty from the perspective of evolution input. These two indicators complement each other, avoiding the one-sidedness of judging by a single indicator.

[0122] Step S33: For the final evolution path where the use case evolution state is partially adapted, extract the path breakpoints marked as unavoidable breakpoints from the breakpoint set to form a key breakpoint set. Perform local path search on each path breakpoint in the key breakpoint set to generate a patch path in the new version logic flow graph. Generate patch use cases based on the patch paths to form a patch use case set.

[0123] See Figure 4 This is a schematic diagram of the key breakpoint patch path generation provided in the embodiments of this application. Figure 4The diagram illustrates the overall framework of the new version's logic flow graph, as well as the complete topological relationships of unavoidable breakpoints, predecessor nodes, successor nodes, patch paths, intermediate nodes, and newly added nodes that are prioritized for traversal. It fully presents the patch path construction logic from the search start point to the search end point. The extraction of the key breakpoint set is performed on each final evolution path whose use case evolution state is marked as partially adapted. From the breakpoint set inherited by the final evolution path, all path breakpoints marked as unavoidable breakpoints are selected, just as... Figure 4 The non-reversible breakpoints marked in the diagram are located between the predecessor and successor nodes, where the original path is interrupted and there is no direct connecting path. These selected path breakpoints are compiled into a critical breakpoint set. The path breakpoints in the critical breakpoint set are the break locations in the final evolution path that cannot be automatically repaired by the existing topology of the new version of the logic flow graph. These break locations need to be specifically covered by patch test cases. Reversible breakpoints are not included in the critical breakpoint set. Although reversible breakpoints cause the original path to be interrupted, connectivity can be restored through reversible paths in the new version of the logic flow graph. After evolution, test cases can continue execution along the reversible path without requiring additional patch test cases.

[0124] For each path breakpoint in the set of critical breakpoints, a local path search is performed in the new version of the logic flow graph. Figure 4 The complete view shows the build environment of the patch path in the new version's logical flow graph. The search starting point is the predecessor node of the path breakpoint in the final evolution path, just as... Figure 4 As shown, the predecessor node is the starting point for searching the patch path, located in the preceding adjacent position of the unavoidable breakpoint. The predecessor new version logical node is the new version logical node in the final evolution path that is located before and adjacent to the path breakpoint. The search endpoint is the successor node of the path breakpoint in the final evolution path, as shown in the diagram. Figure 4 As shown, the successor node is the search endpoint of the patch path, located immediately after the inescapable breakpoint. The successor new version logical node is the new version logical node in the final evolution path that is located after and adjacent to the path breakpoint. Local path search searches for feasible paths connecting the search start point and the search endpoint in the new version logical flow graph. A feasible path is a directed path in the new version logical flow graph that starts from the search start point and reaches the search endpoint along directed logical edges, i.e. Figure 4 The patch path defined in [the document] is the path from the search start point to the search end point. Local path search employs a priority-based graph search algorithm, prioritizing paths that pass through newly added nodes in the set of newly added nodes in the new version, as [example follows]. Figure 4The newly added nodes (preferred nodes) marked in the diagram are the priority nodes selected during the patch path search process. The set of newly added nodes in the new version is generated by graph isomorphic matching in step S10 and includes all new business operations added in the new version requirements. The design basis for prioritizing paths that pass through newly added nodes in the new version is that: path breakpoints often arise from adjustments to business logic caused by requirement changes. Newly added nodes in the new version represent new business operations introduced in the new version requirements. Patching paths passing through newly added nodes in the new version ensure that patch test cases cover the new business logic, enabling patch test cases to not only fix path breakpoints but also expand test coverage.

[0125] If a feasible path is found in the local path search, then the feasible path is defined as the patch path for the path breakpoint, just as... Figure 4 As shown, the patch path starts from the predecessor node, passes through intermediate nodes, and prioritized newly added nodes, finally reaching the successor node to form a complete connected path. The patch path is a sub-path on the new version's logical flow graph. The starting point of the patch path is the predecessor new version logical node of the path breakpoint, and the ending point is the successor new version logical node of the path breakpoint. The intermediate nodes traversed by the patch path are other new version logical nodes accessed during the search process. Figure 4 The intermediate node is located between the predecessor node and the newly added node, and between the newly added node and the successor node. Patch test cases are generated based on the patch path execution. The test steps of the patch test cases are automatically generated based on the sequence of new version logical nodes traversed by the patch path. The generation process reverse-engineers each new version logical node on the patch path into a test step description, using the same method as the reverse-engineering of the final evolution path into test cases in step S34. The expected result of the patch test cases is automatically inferred based on the business semantics of the new version logical node at the end of the patch path. The inference process extracts expected output information from the business entities, business actions, and business conditions contained in the end-point new version logical node, and converts the expected output information into an expected result description. The preconditions of the patch test cases are set as the business state of the new version logical node at the starting point of the patch path, ensuring that the patch test cases can continue execution from the breakpoint of the evolved test cases. The patch test cases for all path breakpoints in the key breakpoint set are summarized to form the patch test case set for the final evolution path.

[0126] If the local path search does not find a feasible path, it means Figure 4In the new version's logical flow graph, there is no connected path between the predecessor node (search start point) and the successor node (search end point). Patch paths for path breakpoints cannot be generated, and these breakpoints are marked as unpatchable breakpoints. The existence of unpatchable breakpoints indicates an unrepairable break in the final evolution path. If the number of unpatchable breakpoints exceeds a preset unpatchable threshold, the use case evolution state of the final evolution path will be changed from partially compatible to incompatible. The threshold for unpatched test cases is set based on the statistical relationship between test case effectiveness and the number of breakpoints. The setting process is as follows: First, existing test case evolution samples are collected from historical version change data. Each sample records the number of unpatched breakpoints in the final evolution path and the effectiveness evaluation results of the evolved test cases in actual test execution. The effectiveness evaluation results are marked by testers based on whether the evolved test cases can achieve the expected test objectives. Then, the sample data is grouped and statistically analyzed according to the number of unpatched breakpoints. The test case effectiveness rate of each group is calculated. The test case effectiveness rate is equal to the number of effective test cases in the group divided by the total number of test cases in the group. Finally, the decreasing trend of test case effectiveness rate as the number of unpatched breakpoints increases is analyzed. The number of unpatched breakpoints corresponding to the test case effectiveness rate falling below the preset effectiveness lower limit is selected as the unpatched threshold. The effectiveness lower limit is set based on test quality management requirements, representing the minimum effectiveness standard that the evolved test cases need to achieve. For example, the lower limit of effectiveness is set to 0.6. Statistical analysis results show that when the number of unpatched breakpoints is 1, the effectiveness of the test case is 0.85. When the number of unpatched breakpoints is 2, the effectiveness of the test case is 0.62. When the number of unpatched breakpoints is 3, the effectiveness of the test case drops to 0.41, which is lower than the lower limit of effectiveness of 0.6. Therefore, the unpatched threshold is set to 2. If there are 3 unpatched breakpoints in the set of critical breakpoints in the final evolution path, the evolution status of the test case will be adjusted to be incompatible.

[0127] Step S33 automatically generates a set of patch test cases for partially adapted final evolution paths through key breakpoint identification and local path search. The filtering of the key breakpoint set focuses patch generation on truly unavoidable breakpoints that need fixing, avoiding redundant processing of automatically circumventable breakpoints. The priority design of local path search ensures that the patch path passes through newly added nodes in the new version as much as possible, allowing patch test cases to cover new business logic while fixing breakpoints, achieving a dual function of repair and expansion. The automatic generation of patch test cases reverses the process from a graph structure representation of the patch path to an executable test case format, ensuring that patch test cases and evolved test cases have the same format specifications and can be directly incorporated into the test management system for management and execution. The identification and state adjustment mechanism for unpatched breakpoints ensures the reliability of partially adapted states, preventing unfixable final evolution paths from being mistakenly judged as fixable.

[0128] Step S34: Convert the final evolution path with a fully adapted test case status into an evolved test case and add it to the final test case set; convert the final evolution path with a partially adapted test case status into an evolved test case and add it to the final test case set along with the corresponding patch test case set; call the test case generation module to generate alternative test cases for the final evolution path with an incompatible test case status and add them to the final test case set; directly add the existing test cases corresponding to the old version test case paths in the unaffected path set to the final test case set; and establish a test case evolution genealogy table to record evolution process information.

[0129] The final test case set is integrated based on the test case evolution status determination result in step S32 and the patch test case set generation result in step S33. The final test case set is a summary of all test cases adapted to the new version requirement document set. For each final evolution path whose test case evolution status is marked as fully adapted, the final evolution path is reverse-converted into test case format to generate evolved test cases. The reverse conversion process converts each new version logical node traversed by the final evolution path into a test step. The business entities, business actions, and business conditions contained in the new version logical nodes are converted into operation descriptions of the test steps. All test steps are arranged according to the node order of the final evolution path to form a test step sequence. The test case identifier of the evolved test cases is generated based on the test case identifiers of the existing test cases corresponding to the old version test case paths. An evolution version tag is appended to the original test case identifier to form a new test case identifier. The inheritance relationship of the test case identifiers facilitates tracing the source of the evolved test cases. The preconditions of the evolved test cases are extracted from the business conditions of the new version logical node at the starting point of the final evolution path, and the expected results of the evolved test cases are inferred from the business semantics of the new version logical node at the ending point of the final evolution path. The generated evolved test cases are added to the final test case set.

[0130] For each final evolution path whose evolution status is marked as partially adapted, the final evolution path is reverse-engineered into a test case format to generate evolved test cases. The conversion method is the same as that for fully adapted final evolution paths. Simultaneously, all patch test cases in the patch test case set corresponding to the final evolution path are added to the final test case set. An association marker is established between the evolved test cases and all patch test cases in the patch test case set. This association marker records the relationship between the test case identifier of the evolved test case and the test case identifier of the patch test case, indicating that the patch test cases in the patch test case set are supplementary tests to the evolved test cases. The establishment of the association marker enables the evolved test cases and their patch test cases to be managed as a test group during test execution, ensuring that the patch test cases are executed after the evolved test cases are executed to fully cover the test scenario.

[0131] For each final evolution path marked as incompatible in the test case evolution state, the test case generation module based on the new version's logical flow graph is invoked to regenerate alternative test cases. The test case generation module starts from the business scenarios covered by the original old version test case paths corresponding to the final evolution path, searches the new version's logical flow graph for new paths covering the same or similar business scenarios, and generates alternative test cases based on the searched new paths. The business scenarios are extracted from the business semantics of the start and end points of the original old version test case paths. The business semantics of the start point represents the initial state of the test scenario, and the business semantics of the end point represents the expected result of the test scenario. The test case generation module searches the new version's logical flow graph for feasible paths starting from new version logical nodes that satisfy the initial state semantics and reaching new version logical nodes that satisfy the expected result semantics, converting the searched feasible paths into alternative test cases. The alternative test cases inherit the test intent of the original old version test case paths and are generated entirely based on the topology of the new version's logical flow graph, ensuring complete adaptation of the alternative test cases to the new version's requirements. The generated alternative test cases are then added to the final test case set.

[0132] For each old version test case path in the unaffected path set formed in step S22, the existing test cases corresponding to the old version test case path are directly added to the final test case set. The path node set of the old version test case paths in the unaffected path set does not intersect with the overall affected area, indicating that these old version test case paths have not passed through the logical area affected by the requirement change. The corresponding existing test cases remain valid under the new version requirements and can continue to be used without any modification. Directly retaining existing test cases minimizes the impact of requirement changes on test assets and preserves the expert experience accumulated by testers to the greatest extent.

[0133] The creation of the test case evolution hierarchy table is performed synchronously with the integration of the final test case set. The test case evolution hierarchy table records the evolution process information from existing test cases to test cases in the final test case set. The test case evolution hierarchy table is stored in tabular form, with each record corresponding to the evolution of an existing test case.

[0134] For example, the structure of the use case evolution genealogy table is shown in Table 1.

[0135] Table 1. Structure of the Use Case Evolution Genealogy Table

[0136]

[0137] The original test case identifier field in the test case evolution genealogy table records the test case identifiers of existing test cases under the old version requirements. The evolved test case identifier field records the test case identifier of the corresponding test case in the final test case set. The changed version field records the version number of this requirement change. The test case evolution status field records the test case evolution status determination result of the final evolution path. The comprehensive energy loss field records the comprehensive energy loss value calculated in step S31. The number of breakpoints field records the total number of path breakpoints in the breakpoint set. The breakpoint location list field records the location information of all path breakpoints in the breakpoint set in the original old version test case path. The patch test case identifier list field records the test case identifiers of all patch test cases in the patch test case set; this field is not empty only when the test case evolution status is partial adaptation. The evolution type field records the evolution processing method of the test case, including three types: direct evolution, patch evolution, and replacement generation.

[0138] The test case evolution spectrum supports incremental traceability analysis during subsequent version changes. When requirements evolve from a new version to an updated version, the evolution history information recorded in the test case evolution spectrum can be used to analyze the evolution trajectory of test cases, determine whether test cases have undergone multiple evolutions, and the quality change trend of each evolution. By analyzing the cumulative changes in comprehensive energy loss in the test case evolution spectrum, test cases frequently affected by changes can be identified. These test cases may cover volatile areas in the business process and require special attention during test design. By analyzing the distribution patterns of breakpoints in the test case evolution spectrum, change hotspots in the logic flow diagram can be identified. These areas have a high frequency of requirement changes and can provide data support for requirement management and version planning.

[0139] Step S30, through energy loss assessment and local patch generation, achieves quantitative control and precise repair of the evolution quality of existing test cases. Traditional methods for handling existing test cases cannot determine whether they are still valid when requirements change; either all existing test cases are discarded, resulting in wasted test assets, or all are retained, leading to ineffective test execution. By separately calculating structural energy loss and functional energy loss, the loss during path deformation is decomposed into two dimensions: structural integrity loss and semantic consistency loss, enabling loss assessment to cover the two main types of problems that may occur during path evolution. The dual judgment of location type and detourability ensures that the location loss contribution value of the breakpoint is precisely matched with the actual impact of the breakpoint. Breakpoints in the starting and ending segments are given high weights to reflect the severity of the break in the critical part of the test case, while detourable breakpoints are given low weights to reflect the mild impact of repairable breakpoints. The introduction of a semantic drift threshold and an over-threshold amplification mechanism differentiates between slight semantic drift and severe semantic deviation, avoiding excessive punishment for normal semantic fine-tuning. The dual judgment of comprehensive energy loss and change crossover ratio makes the use case evolution status determination more robust. It evaluates evolution quality from both the evolution result and evolution input perspectives, avoiding the one-sidedness of a single indicator. The selection of the key breakpoint set focuses patch generation on truly unavoidable breakpoints that need fixing. The priority design of local path search ensures that patch paths pass through newly added nodes in the new version as much as possible, achieving both repair and expansion functions. The three-category classification of use case evolution status differentiates subsequent processing strategies, with each state's use case receiving a processing method matching its evolution quality. The establishment of the use case evolution genealogy table persistently stores evolution process information, providing a data foundation for long-term management and continuous evolution of test assets. The final test case set output in step S30 retains the expert experience of testers carried by the original existing use cases while fully covering all business logic in the new version requirements. This realizes the revitalization and evolution of existing test assets, extending the accumulation of test knowledge from a single version iteration to cross-version lifecycle inheritance, reducing the maintenance cost and knowledge gap risk of regression testing during the continuous iteration of government software.

[0140] Example 2

[0141] This embodiment, based on Embodiment 1, provides an AI-based test requirements analysis and test case generation system, such as... Figure 5 As shown, it includes:

[0142] The logical difference analysis module is used to obtain the old version requirement document set and the new version requirement document set, construct the old version logical flow diagram and the new version logical flow diagram, perform graph isomorphism matching on the old version logical flow diagram and the new version logical flow diagram to generate a logical incremental difference diagram, and determine the overall impact area based on the logical incremental difference diagram;

[0143] Use Case Path Evolution Module: This module is used to obtain the existing test case set, map each existing test case in the existing test case set to the old version logic flow graph to form an existing test case path set, identify the affected path set from the existing test case path set based on the overall impact area, perform path geometric deformation on each old version test case path in the affected path set, and expand the deformed test case path to generate the final evolution path.

[0144] Evolution Status Determination Module: This module calculates the structural and functional energy losses of the final evolution path to obtain the comprehensive energy loss. Based on the comprehensive energy loss and the change crossover ratio, it determines the use case evolution status of the final evolution path. Based on the use case evolution status, it obtains the final test case set and establishes a use case evolution genealogy table.

[0145] Furthermore, in the logic difference analysis module, the method for constructing the old version logic flow graph includes:

[0146] Obtain the old version requirement document set, perform natural language processing on each requirement document in the old version requirement document set, and extract the old version business entity set, old version business action set, and old version business condition set from each requirement document.

[0147] Based on the old version business entity set, old version business action set, and old version business condition set, construct the old version logical node set, analyze the dependency relationship between every two old version logical nodes in the old version logical node set, establish directed logical edges to form the old version logical edge set, and combine the old version logical node set and the old version logical edge set to construct the old version logical flow graph.

[0148] The method for generating a logical incremental difference graph by isomorphic matching of execution graphs includes:

[0149] Calculate the semantic similarity between each old version logical node in the old version logical node set and each new version logical node in the new version logical node set. Based on the semantic similarity, perform node matching to generate a node correspondence table, a set of nodes unique to the old version, and a set of nodes added in the new version.

[0150] Based on the node correspondence table, the set of nodes unique to the old version, and the set of nodes added in the new version, the node changes and edge changes between the old version logic flow graph and the new version logic flow graph are classified and marked to generate a logic increment difference graph.

[0151] Furthermore, in the use case path evolution module, the method for forming the existing use case path set includes:

[0152] Extract test step sequences from each existing test case in the existing test case set. Semantically match each test step in the test step sequence with the old version logical node set to determine the mapping node. Connect all mapping nodes according to the execution order of the test steps to form the old version test case path. Summarize all the old version test case paths to form the existing test case path set.

[0153] The method for identifying the affected path set includes:

[0154] Determine whether the path node set of each old version use case path in the existing use case path set intersects with the overall affected area. Mark the old version use case paths that intersect as affected paths and add them to the affected path set. Calculate the change crossover ratio of the affected paths.

[0155] The methods and systems of this application may be implemented in many ways. For example, they may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order of steps for the method is for illustrative purposes only, and the steps of the method of this application are not limited to the order specifically described above, unless otherwise specifically stated.

[0156] In addition, the parts of the technical solutions provided in the embodiments of this application that are consistent with the implementation principles of the corresponding technical solutions in the prior art have not been described in detail, so as to avoid excessive elaboration.

[0157] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the invention. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A test requirements analysis and test case generation method based on AI, characterized in that, The method includes: The process involves acquiring sets of old and new version requirement documents, performing natural language processing on these documents using a combination of pre-trained language models and rule extraction, constructing old and new version logic flow graphs, calculating the semantic similarity between each logical node in the old version's logical node set and each logical node in the new version's logical node set, performing node matching based on the semantic similarity to generate a node correspondence table, a set of nodes unique to the old version, and a set of newly added nodes in the new version; classifying and labeling node and edge changes between the old and new version logic flow graphs based on the node correspondence table, the set of nodes unique to the old version, and the set of newly added nodes in the new version, generating a logic increment difference graph; and determining the overall impact area based on the logic increment difference graph. Obtain the existing test case set, extract the test step sequence from each existing test case in the existing test case set, perform semantic matching between each test step in the test step sequence and the old version logical node set to determine the mapping node, connect all mapping nodes according to the execution order of the test steps to form the old version test case path, and summarize all the old version test case paths to form the existing test case path set. Determine whether there is an intersection between the path node set of each old version use case path in the existing use case path set and the overall affected area. Mark the old version use case paths that have an intersection as affected paths and add them to the affected path set. Calculate the change cross ratio of the affected paths. The change cross ratio is equal to the number of nodes in the change cross node set divided by the total number of nodes in the path node set. The change cross node set is the intersection of the path node set and the overall affected area. Perform path geometry deformation on each old version use case path in the affected path set, traverse the set of new nodes in the new version, determine the correlation between each new node in the new version and the deformed use case path, insert the relevant new nodes in the new version as extension nodes into the deformed use case path, and generate the final evolution path. The final evolution path inherits the set of breakpoints of the deformed use case path. For each path breakpoint in the final evolution path inheritance breakpoint set, determine whether the original old version logic node corresponding to the path breakpoint is located in the start segment, end segment, or middle segment in the original old version use case path to determine the position type. For path breakpoints located in the middle segment, further determine whether the path segments on both sides of the path breakpoint can be bypassed and connected through other paths in the new version logic flow graph. Mark the path breakpoints that can be bypassed and connected as bypassable breakpoints, and mark the path breakpoints that cannot be bypassed and connected as non-bypassable breakpoints. Determine the position loss contribution value of each path breakpoint based on the position type and bypassability. Accumulate the position loss contribution values ​​of all path breakpoints in the breakpoint set to obtain the structural energy loss. Extract all new version logical nodes traversed by the final evolution path to form an evolved node set, calculate the evolved semantic center vector of the evolved node set, extract all old version logical nodes traversed by the original old version use case path to form an original node set, calculate the original semantic center vector of the original node set, calculate the vector distance between the evolved semantic center vector and the original semantic center vector as the semantic drift distance, and calculate the functional energy loss based on the semantic drift distance; The use case evolution status of the final evolution path is determined based on the comprehensive energy loss and the change crossover ratio. The use case evolution status includes fully adapted, partially adapted, and incompatible. For the final evolution path with a partially adapted use case evolution status, a patch use case set is generated. For the final evolution path with a fully adapted use case evolution status, it is converted into evolved use cases and added to the final test case set. For the final evolution path with a partially adapted use case evolution status, it is converted into evolved use cases and added to the final test case set along with the corresponding patch use case set. For the final evolution path with an incompatible use case evolution status, the use case generation module is called to generate alternative use cases and add them to the final test case set. A use case evolution genealogy table is established to record the evolution process information of the existing test cases to the test cases in the final test case set.

2. The AI-based test requirements analysis and test case generation method according to claim 1, characterized in that, The method for constructing the old version of the logic flow graph includes: Obtain the old version requirement document set, perform natural language processing on each requirement document in the old version requirement document set, and extract the old version business entity set, old version business action set, and old version business condition set from each requirement document. Based on the old version business entity set, old version business action set, and old version business condition set, construct the old version logical node set, analyze the dependency relationship between every two old version logical nodes in the old version logical node set, establish directed logical edges to form the old version logical edge set, and combine the old version logical node set and the old version logical edge set to construct the old version logical flow graph.

3. The AI-based test requirements analysis and test case generation method according to claim 2, characterized in that, The method for generating a node correspondence table, a set of nodes unique to the old version, and a set of nodes added in the new version by performing node matching based on semantic similarity includes: Find the maximum semantic similarity and the corresponding new version logical node. Compare the maximum semantic similarity with the preset node matching threshold. If the maximum semantic similarity exceeds the node matching threshold, the match is successful. Mark the corresponding old version logical node and the new version logical node with the largest semantic similarity as corresponding node pairs and record the corresponding node pairs in the node correspondence table. If the maximum semantic similarity does not exceed the node matching threshold, the corresponding old version logical node is marked as an old version unique node, and the old version unique node is added to the old version unique node set. For new version logical nodes that are not matched by any old version logical nodes, mark them as new version new nodes and add them to the new version new node set.

4. The AI-based test requirements analysis and test case generation method according to claim 3, characterized in that, The method for determining the overall area of ​​influence includes: Identify directly affected regions from the logic increment difference graph, perform a breadth-first traversal of the directly affected regions in the old version logic flow graph to determine the indirectly affected regions, and merge the directly affected regions and the indirectly affected regions into the overall affected region.

5. The AI-based test requirements analysis and test case generation method according to claim 4, characterized in that, The method for geometric deformation of the execution path includes: For each old version logical node on each old version use case path in the affected path set, calculate the single-point traction vector according to the node correspondence table, and calculate the continuity repair vector. Superimpose the single-point traction vector and the continuity repair vector to obtain the final traction vector. Based on the final traction vector of each old version logical node, the old version logical node is moved from its original position in the old version logical flow graph to its target position in the new version logical flow graph. Path breakpoints are marked, and all path breakpoints are summarized to form a breakpoint set. Based on the connection relationship of the original path segments, the connection is re-established in the new version logical flow graph to form the deformed use case path.

6. An AI-based test requirements analysis and test case generation system, used to implement the AI-based test requirements analysis and test case generation method according to any one of claims 1-5, characterized in that, The system includes: The Logical Difference Analysis Module: This module acquires the sets of old and new version requirement documents. It performs natural language processing on the requirement documents using a combination of pre-trained language models and rule extraction to construct old and new version logical flow graphs. It calculates the semantic similarity between each logical node in the old version's logical node set and each logical node in the new version's logical node set. Based on the semantic similarity, it performs node matching to generate a node correspondence table, a set of nodes unique to the old version, and a set of newly added nodes in the new version. Using the node correspondence table, the set of nodes unique to the old version, and the set of newly added nodes in the new version, it classifies and labels the node and edge changes between the old and new version logical flow graphs, generating a logical incremental difference graph. Finally, it determines the overall impact area based on the logical incremental difference graph. The test case path evolution module is used to obtain the existing test case set, extract the test step sequence from each existing test case in the existing test case set, perform semantic matching between each test step in the test step sequence and the old version logical node set to determine the mapping node, connect all mapping nodes according to the execution order of the test steps to form the old version test case path, and summarize all old version test case paths to form the existing test case path set; determine whether there is an intersection between the path node set of each old version test case path in the existing test case path set and the overall affected area, mark the old version test case paths with intersection as affected paths and add them to the affected path set, and calculate the change cross ratio of the affected paths. The change cross ratio is equal to the number of nodes in the change cross node set divided by the total number of nodes in the path node set. The change cross node set is the intersection of the path node set and the overall affected area; perform path geometric deformation on each old version test case path in the affected path set, traverse the new version newly added node set, determine the correlation between each new version newly added node and the deformed test case path, insert the relevant new version newly added nodes as extension nodes into the deformed test case path, and generate the final evolution path. The final evolution path inherits the breakpoint set of the deformed test case path. Evolution State Determination Module: For each path breakpoint in the set of breakpoints inherited from the final evolution path, it determines whether the original old version logic node corresponding to the breakpoint is located in the start segment, end segment, or middle segment of the original old version use case path to determine the position type. For path breakpoints located in the middle segment, it further determines whether the path segments on both sides of the breakpoint can be bypassed and connected through other paths in the new version logic flow graph. Path breakpoints that can be bypassed and connected are marked as bypassable breakpoints, and those that cannot be bypassed and connected are marked as non-bypassable breakpoints. Based on the position type and bypassability, the position loss contribution value of each path breakpoint is determined. The position loss contribution values ​​of all path breakpoints in the breakpoint set are accumulated to obtain the structural energy loss. All new version logic nodes traversed by the final evolution path are extracted to form the evolved node set, and the evolved semantic center vector of the evolved node set is calculated. All old version logic nodes traversed by the original old version use case path are extracted to form the original node set, and the original node set is calculated. The original semantic center vector of the point set is used to calculate the vector distance between the evolved semantic center vector and the original semantic center vector as the semantic drift distance. The functional energy loss is calculated based on the semantic drift distance. The use case evolution status of the final evolution path is determined based on the comprehensive energy loss and the change crossover ratio. The use case evolution status includes fully adapted, partially adapted, and incompatible. For the final evolution path with a use case evolution status of partially adapted, a patch use case set is generated. For the final evolution path with a use case evolution status of fully adapted, the evolved use cases are converted and added to the final test case set. For the final evolution path with a use case evolution status of partially adapted, the evolved use cases are converted and added to the final test case set along with the corresponding patch use case set. For the final evolution path with a use case evolution status of incompatible, the use case generation module is called to generate alternative use cases and add them to the final test case set. A use case evolution genealogy table is established to record the evolution process information of the existing test cases to the test cases in the final test case set.

Images