Test case generation method, device and product based on weighted graph double-path fusion

Abstract

The application discloses a test case generation method and device based on weighted graph double-path fusion and a product, relates to the technical field of software testing, and automatically extracts an entity list and a relationship triple from a requirement document and constructs a directed weighted graph, thereby replacing a traditional manual design and preset rule mode and improving the design efficiency of test cases; forward paths and reverse paths are generated by respectively performing forward search and reverse search, and a defect type value is added in the reverse search process, so that defects of the prior art which focus on normal flow verification and are insufficient in abnormal scene coverage are overcome, bidirectional coverage of normal flow and abnormal scene is realized, and test coverage and defect discovery capability are significantly improved; test cases are generated by matching and fusing the forward paths and the reverse paths and performing priority sorting on the fused paths, automatic and standardized generation of a test case set is realized, and the efficiency, comprehensiveness and quality stability of the test case set are improved.

Description

Technical Field

[0001] This disclosure generally relates to the field of software testing technology, and in particular to a test case generation method, device and product based on weighted graph dual-path fusion. Background Technology

[0002] Designing test cases during cloud platform development is a core means of ensuring high availability, multi-tenant isolation, and the stability of complex distributed systems. Currently, test case design mainly relies on three methods: First, manual design, where test engineers manually write test cases based on requirements documents and business processes, with an efficiency of approximately 10 cases per person per day. This method is highly dependent on the experience of personnel, and test cases designed by different personnel vary significantly in coverage and style. Second, traditional tools, which rely on preset rules or fixed templates to generate test cases, are difficult to handle complex relationships and non-linear dependencies in test requirements, and focus on verifying normal processes, with limited coverage of abnormal scenarios. Third, large language models, which can directly generate test cases, suffer from unstable and untraceable quality due to the black-box nature of the model, resulting in high implementation costs. In addition, existing solutions apply causal graphs to test case design, but only model causal relationships at a qualitative level, without quantifying and evaluating the strength of relationships. Path generation also only uses a one-way deduction method, ignoring the systematic exploration of abnormal scenarios. Another solution uses genetic algorithms to generate test cases, but the convergence speed is slow and the search efficiency is low.

[0003] The above test case generation method has three drawbacks: First, it is inefficient and cannot meet the testing needs of large-scale complex systems; second, it has insufficient coverage, focusing on normal process verification and failing to cover abnormal scenarios; and third, it has unstable quality and high implementation costs. Summary of the Invention

[0004] In view of the aforementioned defects or deficiencies in existing technologies, this paper aims to provide a test case generation method, device, and product based on weighted graph dual-path fusion. This method automatically extracts entity lists and relation triples from requirements documents and constructs a directed weighted graph, replacing traditional manual design and preset rule-based methods, thus improving the efficiency of test case design. By generating forward and reverse paths through separate forward and reverse searches, and adding defect type values ​​during the reverse search process, this method overcomes the shortcomings of existing technologies that focus on normal process verification while neglecting abnormal scenario coverage. It achieves bidirectional coverage of both normal processes and abnormal scenarios, significantly improving test coverage and defect detection capabilities. Furthermore, by matching and fusing forward and reverse paths and prioritizing the fused paths to generate test cases, the method achieves automated and standardized test case generation, resulting in efficient, comprehensive, and quantifiable test case design.

[0005] Firstly, this application provides a test case generation method based on weighted graph dual-path fusion. The method includes: Extract an entity list and relation triples from the requirements document. The entity list contains the entity identifier, entity name, and entity type of each entity. The entity type includes input type and output type. The relation triples include the source entity identifier, relation type, and target entity identifier. A directed weighted graph is constructed based on the entity list and the relation triples. The directed weighted graph contains multiple nodes and weighted directed edges connecting the nodes. Each node corresponds to one entity. The weighted directed edges represent the relationships between entities. The weight of each weighted directed edge is determined based on the frequency of the relationship in the requirements document, the conditional probability of the target entity occurring given the occurrence of the source entity, and the criticality of the target node in the business logic. A forward search is performed on the directed weighted graph to search from the input node along the direction of the weighted directed edges to the output node, generating multiple forward paths; a reverse search is performed on the directed weighted graph to traverse from the output node along the reverse direction of the weighted directed edges, adding defect type values ​​according to predefined defect types during the traversal, generating multiple reverse paths; the input node is the node corresponding to the entity with the input type, and the output node is the node corresponding to the entity with the output type. The multiple forward paths are matched with the multiple reverse paths. Based on the matching results, each reverse path is merged with the matching forward path to obtain multiple merged paths. The multiple merged paths are prioritized and test case sets are generated based on the ranked merged paths.

[0006] In conjunction with the first aspect, in one possible implementation, the weight of the weighted directed edge is determined based on the frequency of the relationship in the requirements document, the conditional probability of the target entity occurring given the occurrence of the source entity, and the criticality of the target node in the business logic, including: The frequency of the relationship in the requirement document is exponentially calculated by a first power, the conditional probability of the target entity occurring given the occurrence of the source entity is exponentially calculated by a second power, and the criticality of the node in the business logic is exponentially calculated by a third power; then the results of each power operation are multiplied together to obtain the weight of the weighted directed edge.

[0007] In conjunction with the first aspect, in one possible implementation, the step of matching the multiple forward paths with the multiple reverse paths, and then merging each of the reverse paths with the matched forward paths based on the matching results to obtain multiple merged paths, includes: An inverted index is established, which records the mapping relationship between node identifiers and the forward path containing the node corresponding to the node identifier; Based on the inverted index and the nodes contained in each of the reverse paths, determine the set of candidate forward paths corresponding to each of the reverse paths; For each of the reverse paths, the matching degree between the reverse path and each candidate forward path in the corresponding candidate forward path set is determined. The candidate forward paths with matching degrees greater than a preset matching degree threshold are merged with the reverse paths to obtain the multiple fused paths.

[0008] In conjunction with the first aspect, in one possible implementation, determining the matching degree between the reverse path and each candidate forward path in the corresponding candidate forward path set includes: For each candidate forward path in the candidate forward path set, determine the number of nodes with common nodes from the nodes contained in the candidate forward path and the nodes contained in the reverse path. The maximum number of nodes in the candidate forward path and the maximum number of nodes in the candidate reverse path is determined, and the ratio of the number of nodes to the maximum number of nodes is determined as the matching degree.

[0009] In conjunction with the first aspect, in one possible implementation, prioritizing the multiple fusion paths and generating a test case set based on the prioritized fusion paths includes: The multiple fusion paths are comprehensively scored based on the matching degree, coverage rate, defect coverage value, and complexity to obtain multiple path scores. The coverage rate is the proportion of the number of nodes included in the fusion path to the total number of nodes in the directed weighted graph. The defect coverage value is determined based on whether the fusion path contains a defect type value. The defect coverage value is 1 when the fusion path contains a defect type marker and 0 when it does not. The complexity is determined based on the path length of the fusion path. The multiple fusion paths are sorted in descending order according to the multiple path scores. The first K fusion paths in the sorted fusion paths are determined as the highest priority core paths, the (K+1)th to (3K)th fusion paths are determined as high priority important paths, the (3K+1)th to (6K)th fusion paths are determined as medium priority general paths, and the (6K+1)th to the last fusion path are determined as low priority edge paths; K is an integer greater than 0. Based on the test steps, expected results, priorities, and coverage of the core path, important path, general path, and edge path, the test cases for the multiple fusion paths are transformed into structured test cases to generate the test case set.

[0010] In conjunction with the first aspect, in one possible implementation, the multiple fusion paths are comprehensively scored based on matching degree, coverage, defect coverage value, and complexity to obtain multiple path scores, including: The path score of the fusion path is obtained by weighting and summing the matching degree, coverage, defect coverage value, and complexity of the fusion path, as well as the weights of the matching degree, coverage, defect coverage value, and complexity; wherein the weights of the matching degree, coverage, and defect coverage value are all positive, and the weight of complexity is negative.

[0011] In conjunction with the first aspect, in one possible implementation, the reverse search is performed on the directed weighted graph to traverse in the reverse direction from the output node along the weighted directed edges, and during the traversal, defect type values ​​are added according to predefined defect types to generate multiple reverse paths, including: Starting from the output node in the directed weighted graph, a path stack is created and the output node is added to the path stack as the starting node to obtain all the predecessor nodes of the output node; For each predecessor node, if the predecessor node meets the preset conditions, the predecessor node is added to the path stack and marked as visited; the preset conditions include that the predecessor node has not been visited, the current path depth has not exceeded the preset depth threshold, and the weight of the weighted directed edge connecting the top node of the path stack and the predecessor node is not lower than the preset weight threshold. For each predecessor node added to the path stack, a defect type value is matched from the defect type library according to the data type of the predecessor node. The matched defect type value is added to the first predecessor node that is successfully matched and has not been added before, and the matching of subsequent predecessor nodes is stopped. The top node of the current path stack is taken as the current node, and the steps of obtaining predecessor nodes and adding predecessor nodes that meet the preset conditions to the path stack are continued for the current node until the predecessor node of the top node does not meet the preset conditions or the top node is an input node. The reverse path is generated according to the predecessor node with the added defect type value and each node in the path stack. The untraversed output nodes in the directed weighted graph are taken as new output nodes. The above steps are repeated until all output nodes are traversed. All generated reverse paths are deduplicated to obtain the multiple reverse paths.

[0012] In conjunction with the first aspect, in one possible implementation, the forward search performed on the directed weighted graph to search from the input node along the direction of the weighted directed edges to the output node, generating multiple forward paths, includes: Starting from the input node in the directed weighted graph, the input node is added to the path stack. Using node importance as a heuristic function, the search proceeds along the direction of the weighted directed edges to the output node. During the search, for each current node found, all subsequent nodes are first selected whose weighted directed edges connecting the current node and its successor node have a weight not lower than a preset weight threshold. Then, the selected successor nodes are pushed onto the path stack in order of increasing node importance. The node importance is determined based on the node's criticality in the business logic. If the search reaches the output node, a forward path is generated based on each node in the current path stack; if the path depth of the current path stack reaches a preset depth threshold, the search stops, and a forward path is generated based on each node in the current path stack. The untraversed input nodes in the directed weighted graph are used as new input nodes, and the above steps are repeated until all input nodes are traversed, generating the multiple forward paths.

[0013] Secondly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method described in the first aspect.

[0014] Thirdly, this application also provides a computer program product. This computer program product includes instructions that, when executed, cause the method described in the first aspect to be implemented.

[0015] This application provides a test case generation method, device, and product based on weighted graph dual-path fusion. By automatically extracting entity lists and relation triples from requirements documents and constructing a directed weighted graph, it realizes the automation transformation of test case design from manual experience dependence to data-driven, significantly improving the efficiency of test case design. By generating forward and reverse paths through forward and reverse searches respectively, and adding defect type values ​​according to predefined defect types during the reverse search process, it overcomes the shortcomings of existing technologies that focus on normal process verification and have insufficient coverage of abnormal scenarios, achieving bidirectional coverage of normal processes and abnormal scenarios, significantly improving test coverage and defect discovery capabilities. By matching and fusing forward and reverse paths, and prioritizing the multiple fused paths to generate test cases, it realizes the automated and standardized generation of test case sets, avoiding the quality instability and untraceability problems caused by black-box generation based on large language models, thereby improving the efficiency, comprehensiveness, and quality stability of test case sets. Attached Figure Description

[0016] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is one of the schematic diagrams of a test case generation method based on weighted graph dual-path fusion in one embodiment; Figure 2 This is the second schematic diagram of a test case generation method based on weighted graph dual-path fusion in one embodiment; Figure 3 This is the third schematic diagram of a test case generation method based on weighted graph dual-path fusion in one embodiment; Figure 4 This is the fourth schematic diagram of a test case generation method based on weighted graph dual-path fusion in one embodiment; Figure 5 This is the fifth schematic diagram of a test case generation method based on weighted graph dual-path fusion in one embodiment; Figure 6 This is the sixth schematic diagram of a test case generation method based on weighted graph dual-path fusion in one embodiment; Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0017] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the invention. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0018] It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of this invention can be combined with each other. The invention will now be described in detail with reference to the accompanying drawings and embodiments. Furthermore, the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The terms "first" and "second," etc., in the specification and claims of the embodiments of this invention are used to distinguish different objects, not to describe a specific order of objects.

[0019] Designing test cases during cloud platform development is a core means of ensuring high availability, multi-tenant isolation, and the stability of complex distributed systems. Currently, test case design mainly relies on three methods: First, manual design, where test engineers manually write test cases based on requirements documents and business processes, with an efficiency of approximately 10 cases per person per day. This method is highly dependent on the experience of personnel, and test cases designed by different personnel vary significantly in coverage and style. Second, traditional tools, which rely on preset rules or fixed templates to generate test cases, are difficult to handle complex relationships and non-linear dependencies in test requirements, and focus on verifying normal processes, with limited coverage of abnormal scenarios. Third, large language models, which can directly generate test cases, suffer from unstable and untraceable quality due to the black-box nature of the model, resulting in high implementation costs. In addition, existing solutions apply causal graphs to test case design, but only model causal relationships at a qualitative level, without quantifying and evaluating the strength of relationships. Path generation also only uses a one-way deduction method, ignoring the systematic exploration of abnormal scenarios. Another solution uses genetic algorithms to generate test cases, but the convergence speed is slow and the search efficiency is low.

[0020] The above test case generation method has three drawbacks: First, it is inefficient and cannot meet the testing needs of large-scale complex systems; second, it has insufficient coverage, focusing on normal process verification and failing to cover abnormal scenarios; and third, it has unstable quality and high implementation costs.

[0021] To address the aforementioned technical problems, this application provides a test case generation method, device, and product based on weighted graph dual-path fusion. The following section combines... Figures 1 to 6 This application describes a test case generation method based on weighted graph dual-path fusion. The execution entity of this method is a computer device, which can be a standalone physical server, cloud server, personal computer, workstation, or a processor module integrated into the test system. For example, when the test case generation method is applied to a cloud platform testing scenario, its execution entity is a test server, which can be a single server, a server cluster, or a virtual machine instance in the cloud platform.

[0022] Reference Figure 1 This is a schematic diagram of the test case generation method based on weighted graph dual-path fusion provided in an embodiment of this application, as shown below. Figure 1 As shown, the test case generation method based on weighted graph dual-path fusion includes the following steps 101 to 104.

[0023] Step 101: Extract the entity list and relation triples from the requirements document. The entity list contains the entity identifier, entity name, and entity type for each entity. The entity type includes input type and output type. The relation triples include the source entity identifier, relation type, and target entity identifier.

[0024] It should be noted that, in addition to input and output types, entity types also include critical and general types.

[0025] An entity identifier (ID) is used to uniquely identify a business entity.

[0026] In addition to the entity identifier, entity name, and entity type for each entity, the entity list also includes importance (between 0 and 1, with a default of 0.5), data type, and numerical range. In one embodiment, if a business entity is represented using a data structure, then the data type of the business entity is string, number, or boolean, and the data range is length, size, etc.

[0027] A relation triple represents a triple (source entity ID, relation type, target entity ID) representing a relationship between entities, supporting causal, constraint, and temporal relationships. In other words, relation types include, but are not limited to, causal, constraint, and temporal relationships.

[0028] Specifically, the computer equipment inputs the requirements document into the information extraction model. The information extraction model extracts entities from the requirements document and identifies the entity type, record data type, and numerical range to obtain a list of entities.

[0029] Meanwhile, the information extraction model can also extract causal relationships, constraint relationships, and temporal relationships from the requirements document, and construct relation triples by combining source entity identifiers and target entity identifiers; thus obtaining the entity list and relation triples. The information extraction model is a traditional Natural Language Processing (NLP) model.

[0030] For example, taking the edge cloud planning and configuration system as an example, the NLP model identifies 25 business entities from the requirements document, including user input, configuration selection, bandwidth check, configuration switching, service restart, status update, result output, business resource data, bandwidth utilization analysis, formula calculation, detailed reports, customer resource data, traffic analysis, edge nodes, and data export. The NLP model also analyzes the entity type, data type, value range, and importance of each business entity, and outputs a standardized entity list after formatting, with each entity assigned a unique entity identifier.

[0031] Continuing with the edge cloud planning and configuration system as an example, the NLP model extracts the relationships between entities from the requirements document. After formatting, it outputs a standardized list of relationship triples. Each relationship triple follows the format (source entity identifier, relationship type, target entity identifier), and the entity identifiers correspond one-to-one with the entity identifiers in the aforementioned entity list.

[0032] Step 102: Construct a directed weighted graph based on the entity list and relation triples. The directed weighted graph contains multiple nodes and weighted directed edges connecting the nodes. Each node corresponds to an entity, and the weighted directed edges represent the relationships between entities. The weight of the weighted directed edges is determined based on the frequency of the relationship in the requirements document, the conditional probability of the target entity occurring given the occurrence of the source entity, and the criticality of the target node in the business logic.

[0033] The directed weighted graph is a directed graph with weights; the nodes in the graph represent business entities, such as input nodes, output nodes, ordinary nodes, and key nodes; the edges in the graph represent the relationships and weights between business entities, which are used to accurately model the relationships of business logic.

[0034] The target node is the node corresponding to the target entity in the relation triple, and the node corresponding to the source entity in the relation triple is the source node; weighted directed edges point from the source node to the target node. For example, for the relation triple (user input, causal relationship, configuration selection), the source node is the user input node, and the target node is the configuration selection node.

[0035] Entities of type input correspond to input nodes, which are used to trigger business processes; entities of type output correspond to output nodes, which are used to indicate the termination point of the business process; entities of type critical correspond to critical nodes, which are traversed first in the path search; entities of type ordinary correspond to ordinary nodes, which represent regular business processing steps.

[0036] Specifically, the construction of a directed weighted graph involves sequentially performing node registration, edge addition, adjacency list creation, and index creation. The specific construction process is as follows: Node Registration: Each entity in the entity list is traversed, and a unique node object is created for each entity. The node object contains attributes such as entity ID, name, type (input node / output node / normal node / critical node), importance, data type, numerical range, outgoing edge list, and incoming edge list. The outgoing edge list and incoming edge list are initialized to empty lists when the node is created. The system assigns a globally unique node identifier (NodeID) to each node and stores the node object in the node pool, establishing a mapping relationship between NodeID and node object to ensure that the source and target nodes can be quickly located when adding subsequent edges.

[0037] Edge addition: Traverse the set of relation triples. For each triple (source entity ID, relation type, target entity ID), perform the following operations: First, find the corresponding source and target node objects through NodeID mapping; then, based on the edge weight values ​​obtained in the weight calculation stage, create weighted edge objects. These edge objects contain attributes such as source node reference, target node reference, relation type, weight value, support, and confidence; finally, add the edge objects to the outgoing edge list of the source node and the incoming edge list of the target node, establishing a bidirectional association between nodes and edges. After addition, the outgoing edge list of the source node contains references to all edges originating from that source node, and the incoming edge list of the target node contains references to all edges ending at that target node. Through these outgoing and incoming edge lists, each node can quickly obtain all its successor and predecessor nodes, providing a data structure foundation for subsequent forward and reverse searches.

[0038] Adjacency List Construction: Based on the registered nodes and added edges, an adjacency list representation of the graph is constructed. The adjacency list adopts a hash table structure, where the key is the node ID and the value is the list of outgoing edges of that node. A reverse adjacency list is also constructed to support reverse path search; the key of the reverse adjacency list is the node ID and the value is the list of incoming edges of that node. The adjacency list supports node access and edge traversal with O(1) time complexity, providing an efficient data structure foundation for subsequent forward and reverse searches.

[0039] Index Creation: To accelerate subsequent path matching and query operations, multiple index structures are established: ① Node Type Index: Node IDs are grouped and stored according to node type (input / output / general / critical), supporting quick filtering of nodes of specific types; ② Relationship Type Index: Edge objects are grouped and stored according to relationship type (causal / constraint / temporal relationship), supporting quick location of relationships of specific types; ③ Node Name Index: A mapping is established between node names and NodeIDs, supporting quick node lookup by name; ④ Weight Index: An index is created for edges based on weight value ranges, supporting edge filtering by weight threshold. The creation of the above indexes is based on node objects in the node pool and already created edge objects, without relying on the adjacency table structure. They can be executed independently after edges are added, and there is no dependency on the adjacency table.

[0040] By executing the above four sub-steps in an orderly manner, the complete construction of a directed weighted graph from entities and relationships is completed, providing a structured graph data foundation for subsequent bidirectional path fusion.

[0041] For example, if the implementation environment is an edge cloud planning and configuration system, including core modules such as configuration switching, number of service resources, customer resource usage, and system interaction, the entity examples are: user input, configuration selection, bandwidth check, configuration switching (critical), service restart, status update, result output, service resource data, bandwidth utilization analysis, formula calculation (critical), detailed reports, customer resource data, traffic analysis, edge nodes, and data export; the relationship examples are: user input → configuration selection → bandwidth check → configuration switching → service restart → result output; user input → configuration selection → bandwidth check → configuration switching → status update → result output; service resource data → bandwidth utilization analysis → formula calculation → detailed reports; customer resource data → traffic analysis → edge nodes → data export; then a directed weighted graph with 52 edges can be constructed.

[0042] Step 103: Perform a forward search on the directed weighted graph to search from the input node along the direction of the weighted directed edges to the output node, generating multiple forward paths; perform a reverse search on the directed weighted graph to traverse from the output node along the reverse direction of the weighted directed edges, and add defect type values ​​according to the predefined defect types during the traversal, generating multiple reverse paths; the input node is the node corresponding to the entity with the input type, and the output node is the node corresponding to the entity with the output type.

[0043] The defect type value can be boundary overflow, null pointer, data inconsistency, timing error, etc.

[0044] It should be noted that the forward search and reverse search are performed independently in step 103. The forward search generates multiple forward paths to describe normal business processes; the reverse search generates multiple reverse paths to describe abnormal business scenarios. Both use the directed weighted graph constructed in step 102 as the processing object, but the search directions are opposite and the purposes of the generated paths are different. After step 103 is completed, the forward and reverse paths are output separately for matching and merging in subsequent steps (such as step 104).

[0045] Specifically, a forward search is performed on the directed weighted graph, searching from the input node along the direction of the weighted directed edges to the output node. Taking the edge cloud planning and configuration system as an example, starting from the user input node, the search proceeds sequentially through the configuration selection node, bandwidth check node, and configuration switching node. From the configuration switching node, the search continues along the service restart branch and the status update branch to the result output node, generating two forward paths. Two additional forward paths are generated starting from the business resource data node and the customer resource data node, respectively. During the search process, a weighted directed edge is added to the path stack only if its weight is not lower than a preset weight threshold. The path extension stops when the path depth reaches a preset depth threshold, and the critical path is explored first, using node importance as a heuristic function.

[0046] A reverse search is performed on the directed weighted graph, traversing in the reverse direction of the weighted directed edges from the output node. Taking the edge cloud planning and configuration system as an example, starting from the result output node, a reverse search is performed along the service restart branch and the status update branch respectively. A null pointer defect type value is injected at the bandwidth check node, and a boundary overflow defect type value is injected at the customer resource data node, generating two reverse paths. Starting from the detailed report node and the data export node respectively, a reverse search is performed, and defect type values ​​are injected at nodes that meet the conditions, generating two more reverse paths. During the traversal, the predecessor node is added to the path stack only if it meets the preset conditions (not visited, depth not exceeding the threshold, weight not lower than the threshold). All generated reverse paths are deduplicated to obtain multiple unique reverse paths.

[0047] For example, if the implementation environment is an edge cloud planning and configuration system, the forward path is: user input → configuration selection → bandwidth check → configuration switch → service restart → result output. Reverse path 1 is: result output ← service restart ← configuration switch ← bandwidth check (injecting a null pointer exception). Reverse path 2 is: data export ← edge node ← traffic analysis ← customer resource data (injecting a boundary overflow exception).

[0048] Step 104: Match multiple forward paths with multiple reverse paths. Based on the matching results, merge each reverse path with the matching forward path to obtain multiple merged paths. Prioritize the multiple merged paths and generate a test case set based on the sorted merged paths.

[0049] Specifically, multiple forward paths are matched with multiple reverse paths. Taking the edge cloud planning and configuration system as an example, the reverse path "Result Output ← Service Restart ← Configuration Switch ← Bandwidth Check (Null Pointer Injection Defect)" is matched with the forward path "User Input → Configuration Selection → Bandwidth Check → Configuration Switch → Service Restart → Result Output". The node sequences of the two paths highly overlap, confirming a match. This reverse path is then matched with another forward path "User Input → Configuration Selection → Bandwidth Check → Configuration Switch → Status Update → Result Output". Both paths share common core nodes (bandwidth check, configuration switch, result output), confirming another match. The reverse path is then matched with the forward path "Business Resource Data → Bandwidth Utilization Analysis → Formula Calculation → Detailed Report". Since they have no common nodes, a mismatch is confirmed. The same method is used to match the remaining reverse paths to identify matching path pairs.

[0050] Then, path fusion is performed, using the forward path as the base path and adding the defect type value carried by the reverse path at the corresponding nodes. For example, after fusion, four fused paths are obtained: "User Input → Configuration Selection → Bandwidth Check (Null Pointer) → Configuration Switch → Service Restart → Result Output", "User Input → Configuration Selection → Bandwidth Check (Null Pointer) → Configuration Switch → Status Update → Result Output", "Business Resource Data (Boundary Overflow) → Bandwidth Utilization Analysis → Formula Calculation → Detailed Report", and "Customer Resource Data (Boundary Overflow) → Traffic Analysis → Edge Node → Data Export". For fused paths that overlap, only one is retained.

[0051] The converged paths are then prioritized. For example, converged path 1, "User Input → Configuration Selection → Bandwidth Check (Null Pointer) → Configuration Switch → Service Restart → Result Output," covers the core configuration switching business process and is given the highest priority; converged path 2, "User Input → Configuration Selection → Bandwidth Check (Null Pointer) → Configuration Switch → Status Update → Result Output," covers another branch of configuration switching and is given a high priority; the remaining two converged paths cover the business resource analysis and customer resource analysis processes and are given a medium priority.

[0052] Finally, test case sets are generated based on the sorted fusion paths. Taking the highest priority fusion path "User Input → Configuration Selection → Bandwidth Check (Null Pointer) → Configuration Switch → Service Restart → Result Output" as an example, each node is mapped to the corresponding test operation steps according to the node sequence: first, input the user request parameters; then, select the target configuration version; perform a bandwidth check (set the bandwidth of a source with a null pointer and check it); perform a configuration switch; perform a service restart; and finally, verify the result output. The expected results are successful configuration switch, normal service restart, and system error logs. The priority of the fusion path is used as the priority of the test cases, and the number of path nodes is used as the estimated coverage. The other fusion paths are transformed in the same way, ultimately generating a test case set containing multiple test cases.

[0053] The test case generation method based on weighted graph dual-path fusion provided in this application automatically extracts entity lists and relation triples from requirements documents and constructs a directed weighted graph, realizing the automation transformation of test case design from manual experience dependence to data-driven, significantly improving the efficiency of test case design. By generating forward and reverse paths through forward and reverse searches respectively, and adding defect type values ​​according to predefined defect types during the reverse search process, it overcomes the shortcomings of existing technologies that focus on normal process verification and have insufficient coverage of abnormal scenarios, achieving bidirectional coverage of normal processes and abnormal scenarios, significantly improving test coverage and defect discovery capabilities. By matching and fusing forward and reverse paths, and prioritizing the multiple fused paths to generate test cases, it realizes the automated and standardized generation of test case sets, avoiding the quality instability and untraceability problems caused by black-box generation based on large language models, thereby improving the efficiency, comprehensiveness, and quality stability of test case sets.

[0054] In one embodiment, the "weight of the weighted directed edge is determined based on the frequency of the relationship in the requirement document, the conditional probability of the target entity occurring under the condition that the source entity occurs, and the criticality of the target node in the business logic" mentioned in step 102 is achieved through the following steps in this embodiment.

[0055] The frequency of the relationship in the requirements document is exponentially calculated using the first power; the conditional probability of the target entity occurring given the occurrence of the source entity is exponentially calculated using the second power; and the criticality of the target node in the business logic is exponentially calculated using the third power. The results of each power operation are then multiplied to obtain the weight of the weighted directed edge.

[0056] The criticality of a node in the business logic is assessed by the information extraction model during the entity analysis phase.

[0057] The frequency of a relationship appearing in the requirements document can be denoted as support, which measures the reliability and prevalence of the relationship.

[0058] The conditional probability of the target entity occurring given that the source entity has occurred can be denoted as confidence. Confidence can measure the strength and credibility of a relationship.

[0059] The criticality of a target node in the business logic can be denoted as Importance. Importance is evaluated by the information extraction model during the entity analysis phase and ranges from [0, 1]. Importance can affect the priority of path search and weight calculation.

[0060] Specifically, based on the frequency of the relationship in the requirements document (Support), the conditional probability of the target entity occurring under the condition of the source entity occurring (Confidence), and the importance of the target node in the business logic (Importance), the weight of the weighted directed edge is calculated using the power weighting formula shown in Equation (1).

[0061] Weight = Support^0.3×Confidence^0.5×Importance^0.2 (1) In equation (1), the first power is 0.3, the second power is 0.5, and the third power is 0.2; the sum of the three powers is 1. Support = number of times the relation appears / total number of relations, Confidence = P(target / source), where target represents the target entity and source represents the source entity. The second power of confidence is the core, support is the foundation, and importance is auxiliary, with the second power > the first power > the third power.

[0062] For example, taking the edge cloud planning and configuration system as an example, a directed weighted graph containing 52 weighted directed edges is generated. Five of the 52 weighted directed edges are shown in column 1 of Table 1, and the weights of the five weighted directed edges are shown in column 5 of Table 1.

[0063] Table 1

[0064] The following is an example of weight calculation using "Bandwidth Check → Configuration Switch" in Table 1 as an example. The data comes from the requirements analysis document.

[0065] Analyzing 50 business requirement scenarios, 40 of which involve the relationship of "bandwidth check → configuration switch", Support=40 / 50=0.80.

[0066] Of the 45 business requirement scenarios that mentioned "bandwidth check", 40 of them had a "configuration switch" operation afterward, Confidence=40 / 45≈0.89.

[0067] Importance was determined to be 0.90 by the information extraction model.

[0068] Weight=Support^0.3×Confidence^0.5×Importance^0.2=0.80^0.3×0.89^0.5×0.90^0.2≈0.935×0.943×0.979≈0.863.

[0069] In one embodiment, step 104, which involves "matching multiple forward paths with multiple reverse paths, and merging each reverse path with the matched forward path to obtain multiple fused paths," is implemented in this embodiment by... Figure 2 Steps 201 to 203 shown are implemented.

[0070] Step 201: Build an inverted index. The inverted index records the mapping relationship between node identifiers and the forward paths of the nodes containing the node identifiers.

[0071] Step 202: Based on the inverted index and the nodes contained in each reverse path, determine the set of candidate forward paths corresponding to each reverse path.

[0072] Step 203: For each reverse path, determine the matching degree between the reverse path and each candidate forward path in the corresponding candidate forward path set. Merge the candidate forward paths with matching degrees greater than the preset matching degree threshold with the reverse paths to obtain multiple fused paths.

[0073] The matching degree is the degree of node matching between the candidate forward path and the reverse path, and its range is [0, 1].

[0074] Specifically, building an inverted index involves establishing a mapping relationship between "node → set of forward paths containing that node". The specific construction process includes initializing the index structure, traversing the set of forward paths, and index optimization.

[0075] The initial index structure is as follows: create a hash table as the index container, where the key is the node ID and the value is a list of path IDs (storing the identifiers of all forward paths containing the node).

[0076] Traversing the set of forward paths involves performing the following operations for each forward path: obtaining the unique node identifier (PathID) of the current forward path; traversing all nodes on the current forward path; and adding the current PathID to the path list corresponding to each traversed node.

[0077] The index is optimized as follows: the path list for each node can be sorted by path length, which makes it easier to return forward paths with fewer nodes first; an auxiliary mapping from node name to node ID is established to support quick path lookup by node name.

[0078] The process of determining multiple fusion paths includes quickly locating candidate forward paths, calculating and filtering matching degrees, and fusion of paths.

[0079] The method for quickly locating candidate forward paths is as follows: For each reverse path, extract the set of all nodes contained in the reverse path; then use the inverted index (node ​​→ path set mapping) to obtain the set of forward paths corresponding to each node in the set of nodes; calculate the intersection of these sets of forward paths to obtain the set of candidate forward paths for the reverse path (which also includes forward paths containing all nodes of the reverse path).

[0080] Matching Degree Calculation and Filtering: The matching degree is defined as the degree of node matching between a candidate forward path and an inverse path, ranging from [0,1]. For each inverse path, the matching degree between the inverse path and each candidate forward path in the candidate forward path set is calculated one by one. Then, candidate forward paths with matching degrees lower than a preset matching degree threshold are filtered out, and target candidate forward paths with matching degrees higher than the preset matching degree threshold are retained to participate in subsequent path fusion; this continues until the target candidate forward path corresponding to each inverse path is obtained. For example, if the preset matching degree threshold is set to 0.6, only target candidate forward paths with matching degrees greater than 0.6 are retained.

[0081] Path fusion: The forward paths of each target candidate filtered by the threshold are merged with their corresponding reverse paths to generate multiple fused paths. The fusion method is as follows: the normal process node sequence of the forward path of the target candidate is retained, and the defect type value is added to the target node in the forward path that corresponds to the defect type value carried by the reverse path.

[0082] It should be noted that the mapping relationship of "node → set of forward paths containing that node" established in this embodiment is essentially an inverted index structure, not a forward index. This is because: the mapping relationship of a forward index is "document / path → containing words / nodes", and its typical application scenario is to find the containing nodes when the path is known; the mapping relationship of an inverted index is "word / node → document / path containing it", and its typical application scenario is to find the path containing that known node when the node is known.

[0083] In this embodiment, the core value of the inverted index lies in the fact that after the reverse path is generated, all forward paths containing any node on the reverse path can be quickly located, thereby efficiently calculating the matching degree of the forward and reverse paths. For example, if the reverse path passes through nodes A, B, and C, the inverted index can be used to obtain the set of forward paths containing A, B, and C respectively, and then find the forward path that highly matches the reverse path for fusion.

[0084] The principle of inverted index acceleration: By pre-establishing the mapping from nodes to paths, the complexity of candidate path location is reduced from O(N×M) (N is the number of forward paths and M is the number of reverse paths) to O(K×L) (K is the number of reverse path nodes and L is the average number of paths corresponding to each node), which significantly improves matching efficiency.

[0085] For example, if the candidate forward path is user input → configuration selection → bandwidth check → configuration switch → service restart → result output, and the reverse path is result output ← service restart ← configuration switch ← bandwidth check (injection of boundary overflow defect), the common nodes are the four nodes of bandwidth check, configuration switch, service restart and result output, and the matching degree is 0.67, then the fused path is user input → configuration selection → bandwidth check (boundary overflow) → configuration switch → service restart → result output.

[0086] In one embodiment, the "determining the matching degree between the reverse path and each candidate forward path in the corresponding candidate forward path set" mentioned in step 203 is, in this embodiment, achieved through... Figure 3 Steps 301 and 302 shown are implemented.

[0087] Step 301: For each candidate forward path in the candidate forward path set, determine the number of nodes with common nodes from the nodes contained in the candidate forward path and the nodes contained in the reverse path.

[0088] Step 302: Determine the maximum number of nodes among the number of nodes in the candidate forward path and the number of nodes in the reverse path, and determine the ratio of the number of nodes to the maximum number of nodes as the matching degree.

[0089] Specifically, for each candidate forward path in the candidate forward path set corresponding to the reverse path, the number of nodes common to both the candidate forward path and the reverse path is found from all nodes contained in both paths. Then, the maximum number of nodes between the number of nodes in the candidate forward path and the number of nodes in the reverse path is taken as the quotient, which is the number of common nodes divided by the maximum number of nodes. The matching degree between the candidate forward path and the reverse path is determined. The formula for calculating the matching degree is shown in Equation (2).

[0090] Match = Number of common nodes in the forward and reverse paths / max(Number of candidate forward path nodes, Number of candidate reverse path nodes) (2) In equation (2), max represents the operation of finding the maximum value.

[0091] For example, if the candidate forward path includes 4 nodes {A,B,C,D} and the reverse path includes 4 nodes {B,C,D,E}, then the common nodes of the forward and reverse paths are B, C, and D, the number of common nodes of the forward and reverse paths is 3, and the matching degree = 3 / max(4,4) = 0.75.

[0092] In one embodiment, the step 104, "prioritizing multiple fusion paths and generating test case sets based on the prioritized fusion paths," is implemented in this embodiment by... Figure 4 Steps 401 to 403 shown are implemented.

[0093] Step 401: Analyze the multiple fusion paths based on matching degree, coverage, defect coverage value, and complexity to obtain multiple path scores. Coverage is the proportion of the number of nodes in the fusion path to the total number of nodes in the weighted graph. Defect coverage value is determined based on whether the fusion path contains defect type values. Complexity is determined based on the path length of the fusion path.

[0094] Step 402: Sort the multiple fusion paths in descending order according to the multiple path scores, and determine the first K fusion paths as the highest priority core paths, the K+1 to 3Kth fusion paths as high priority important paths, the 3K+1 to 6Kth fusion paths as medium priority general paths, and the 6K+1 to the last fusion path as low priority edge paths; K is an integer greater than 0.

[0095] Step 403: Convert the multiple fusion paths into structured test cases. Each test case includes test steps, expected results, priority, and coverage, generating a test case set.

[0096] It should be noted that the analytic hierarchy process (AHP) can be used to comprehensively score each fusion path. That is, each fusion path is comprehensively scored from four dimensions: matching degree, coverage, defect coverage value, and complexity.

[0097] The defect coverage value is a binary label. The defect coverage value is 1 when the fusion path contains the defect type label, and 0 when it does not.

[0098] First, calculate the matching degree, coverage, defect coverage value, and complexity of each fusion path. Specifically, based on the candidate forward and reverse paths associated with the fusion path, calculate the matching degree (Match) of each fusion path using Equation (2); calculate the coverage of each fusion path based on the ratio of the number of nodes contained in the fusion path (referred to as the number of path nodes) to the total number of nodes in the directed weighted graph (referred to as the total number of graph nodes), where Coverage = number of path nodes / total number of graph nodes; for a fusion path, if the path contains a defect type marker (carried from the reverse path), then the defect coverage value (DefectCoverage) = 1; otherwise, the defect coverage value = 0.

[0099] Based on the path length of the fusion path, the complexity of each fusion path is calculated using Equation (3).

[0100] Complexity = min(path length × 0.05, 0.3) (3) In equation (3), min represents the operation of finding the minimum value.

[0101] Secondly, based on the matching degree, coverage, defect coverage value and complexity of each fusion path, a comprehensive score can be obtained by using a predetermined algorithm formula or a pre-trained scoring model to obtain the path score of each fusion path.

[0102] Subsequently, all fusion paths are ranked by TOP-K priority, with the K value used as a boundary reference value. Priority labels are dynamically assigned based on the path score distribution. The priority ranking process includes score ranking, K value boundary determination, four-level priority division, and priority label assignment.

[0103] Scoring and sorting: Sort multiple fusion paths in descending order according to the scores of multiple paths to form an ordered path list.

[0104] K-value boundary determination: K-value is a priority boundary reference value (default K-value is 10), representing the upper limit of the number of P0 core paths. For example, when K=10, the top 10 fusion paths in terms of score are P0 core paths; when K=12, the top 12 fusion paths in terms of score are P0 core paths.

[0105] The four levels of optimization and classification are as follows: P0 core paths are the fusion paths with scores ranked 1 to K, corresponding to the highest priority and must be tested; P1 important paths are the fusion paths with scores ranked K+1 to 3K, corresponding to high priority and strongly recommended for testing; P2 general paths are the fusion paths with scores ranked 3K+1 to 6K, corresponding to medium priority and recommended for testing; P3 marginal paths are the fusion paths with scores ranked 6K and below, corresponding to low priority and should be tested as needed.

[0106] Priority label assignment: Assign a corresponding priority label (P0 / P1 / P2 / P3) to each fusion path and record metadata such as ranking, path score, and priority for test engineers to refer to.

[0107] Finally, the core path, important path, general path, and edge path are converted into structured test cases, including test steps, expected results, priorities, and coverage.

[0108] For example, if the implementation environment is an edge cloud planning and configuration system, which includes core modules such as configuration switching, business resource data, customer resource usage, and system interaction, and the parameter configuration includes: a preset weight threshold of 0.2 (filtering weak relationships), a preset matching degree threshold of 0.6 (forward and reverse path matching degree threshold), a path depth limit of 5 (to prevent excessively long paths), and TOP-K of 10 (priority boundary reference value, TOP-10 corresponds to the P0 core path), as well as scoring weights (matching degree weight of 38%, coverage weight of 32%, defect coverage weight of 23%, and complexity weight of -7%), then the generated test case set includes test case 1 and test case 2.

[0109] Test Case 1 (P0 core path, null pointer defect): The test path is user input → configuration selection → bandwidth check (injecting null pointer defect) → configuration switch → service restart → result output. The test objective is to verify the system's fault tolerance capability for null pointer exceptions during bandwidth checks. The steps are: enter the configuration switch page → select the target configuration version → the system performs a bandwidth check (simulating a null pointer as the bandwidth data source) → observe the system response. The expected result is that the system catches the null pointer exception and prompts "Bandwidth data is abnormal, please check the data source", refuses to execute the configuration switch, records the exception log, and the interface does not crash. The priority is P0 (core defect scenario, mandatory test). The defect type is null pointer. The path score is 0.540 (matching degree 0.67, coverage 0.24, defect coverage value 1.0, complexity 0.30, Score=0.38×0.67+0.32×0.24+0.23×1.0-0.07×0.30).

[0110] Test Case 2 (P0 core path, boundary overflow defect): The test path is customer resource data (injecting boundary overflow defect) → traffic analysis → edge node → data export. The test objective is to verify the system's fault tolerance capability for customer resource data boundary overflow anomalies. The steps are: enter the customer resource analysis page → select 100001 customer resources (exceeding the upper limit of 100000) → execute traffic analysis → observe the system response. The expected result is that the system prompts "The number of customer resources exceeds the range [0, 100000]", refuses to execute traffic analysis, records the exception log, and the interface does not crash. The priority is P0 (core defect scenario, mandatory test). The defect type is boundary overflow. The path score is 0.651 (matching degree 1.0, coverage 0.16, defect coverage value 1.0, complexity 0.15, Score=0.38×1.0+0.32×0.16+0.23×1.0-0.07×0.15).

[0111] The test results are as follows: The system generated 83 test paths and assigned priorities according to the scores (10 core paths P0, 20 important paths P1, 30 general paths P2, and 23 edge paths P3), generating a total of 166 test cases, with a coverage rate of 96.8%. The generation time was 3 minutes (approximately 55 test cases / minute), and all four types of defects were fully covered.

[0112] It should be noted that when the total number of merged paths is less than the boundary of a certain level, the boundaries of subsequent levels are automatically adjusted. For example, if the total number of merged paths after descending sorting is 83, and K=10, then P0 core paths are paths 1 to 10, P1 important paths are paths 11 to 30 (20 paths), P2 general paths are paths 31 to 60 (30 paths), and P3 edge paths are paths 61 to 83 (23 paths).

[0113] In one embodiment, the step 401, "to comprehensively score multiple fusion paths based on matching degree, coverage, defect coverage value and complexity, and obtain multiple path scores", is implemented through the following steps.

[0114] The path score of the fusion path is obtained by weighting and summing the matching degree, coverage, defect coverage value, and complexity of the fusion path, as well as the weights of matching degree, coverage, defect coverage value, and complexity. Among them, the weights of matching degree, coverage, and defect coverage value are all positive, while the weight of complexity is negative.

[0115] Specifically, based on the Match, Coverage, Defect Coverage and Complexity of each fusion path, a comprehensive score is calculated using Equation (4), and the path score of each fusion path is calculated.

[0116] Score=0.38×Match+0.32×Coverage+0.23×DefectCoverage-0.07×Complexity (4) In equation (4), the weight of matching degree is 0.38, the weight of coverage rate is 0.32, the weight of defect coverage value is 0.23, and the weight of complexity is -0.07. To increase the priority of abnormal cases, the score containing reverse direction can be set to be 0.23 higher than that of pure forward direction.

[0117] In one embodiment, the step 103 mentioned, "performing a reverse search on the directed weighted graph to traverse from the output node along the reverse direction of the weighted directed edges, and adding defect type values ​​according to predefined defect types during the traversal to generate multiple reverse paths," in this embodiment, is achieved through... Figure 5Steps 501 to 504 shown are implemented.

[0118] Step 501: Starting from the output node in the directed weighted graph, create a path stack and add the output node as the starting node to the path stack to obtain all the predecessor nodes of the output node.

[0119] Step 502: For each predecessor node, if the predecessor node meets the preset conditions, the predecessor node is added to the path stack and marked as visited. The preset conditions include that the predecessor node has not been visited, the current path depth has not exceeded the preset depth threshold, and the weight of the weighted directed edge connecting the top node of the path stack and the predecessor node is not lower than the preset weight threshold.

[0120] Step 503: For each predecessor node added to the path stack, match the defect type value from the defect type library according to the data type of the predecessor node. Add the matched defect type value to the first predecessor node that is successfully matched and has not been added with a defect type value, and stop matching subsequent predecessor nodes. Take the top node of the current path stack as the current node, and continue to perform the steps of obtaining predecessor nodes and adding predecessor nodes that meet the preset conditions to the path stack for the current node until the predecessor node of the top node does not meet the preset conditions or the top node is an input node. Generate a reverse path based on the predecessor node with added defect type value and each node in the path stack.

[0121] Step 504: Take the untraversed output nodes in the directed weighted graph as new output nodes, and repeat the above steps until all output nodes have been traversed. Perform deduplication on all generated reverse paths to obtain multiple reverse paths.

[0122] Specifically, for each output node in the directed weighted graph, perform the following reverse depth-first search (DFS) traversal: Starting from the output node in the directed weighted graph, a path stack is created, and the output node is added to the path stack as the starting node. All predecessor nodes of the output node are obtained. For each predecessor node, if the predecessor node meets a preset condition, it is added to the path stack and marked as visited. The preset conditions include: the predecessor node has not been visited, the current path depth does not exceed a preset depth threshold, and the weight of the weighted directed edge connecting the top node of the stack to the predecessor node is not less than a preset weight threshold. For example, the preset depth threshold is 5, and the preset weight threshold is 0.2.

[0123] For each predecessor node added to the path stack, defect type values ​​are matched against the predefined defect type library according to their data type, following the order of addition. The matched defect type value is added to the first predecessor node that has a successful match and has not yet had a defect type value added, and matching of subsequent predecessor nodes stops. For example, if the predecessor nodes added to the path stack are node A, node B, and node C in that order, the system first checks if node A's data type can be matched with a corresponding defect type value in the defect type library. If it matches and node A has not yet had a defect type value added, the defect type value is added to node A, and node B and node C are not checked subsequently. If node A cannot match or its defect type value has already been added, the system continues checking node B, and so on.

[0124] Take the top node of the current path stack as the current node, and continue to perform the steps of obtaining the predecessor node and adding the predecessor node that meets the preset conditions to the path stack, until the predecessor node of the top node does not meet the preset conditions or the top node is an input node. Generate a reverse path based on the predecessor node with the added defect type value and each node in the path stack.

[0125] Then, take the untraversed output nodes in the directed weighted graph as new output nodes, and repeat the above steps until all output nodes have been traversed, generating a set of reverse paths.

[0126] Finally, all reverse paths in the reverse path set are deduplicated to remove identical reverse paths, resulting in multiple unique reverse paths, thus ensuring the uniqueness of the final multiple reverse paths.

[0127] Through the above process, reverse paths containing multiple defect scenarios can be generated. Each reverse path is marked with a specific defect type value and injection location, providing a basis for abnormal scenario coverage for subsequent path fusion and test case generation.

[0128] For example, taking the reverse search of the edge cloud planning and configuration system as an example, the reverse traversal starts from the output node "Result Output". The predecessor nodes of the Result Output node include service restart nodes and status update nodes. For each predecessor node, it is checked whether it meets the preset conditions (not visited, depth not exceeding the threshold, and the weight of the connection edge not lower than the preset weight threshold). Predecessor nodes that meet the preset conditions are added to the path stack and marked as visited. For each predecessor node added to the path stack, the defect type value is matched from the defect type library according to its data type in the order of addition. If the data type of the service restart node matches the corresponding defect type value in the defect type library, the defect type value (e.g., null pointer defect) is added at the first successfully matched service restart node that has not had a defect type value added, and the matching of subsequent predecessor nodes is stopped. Then, the current top node of the stack is taken as the current node, and the steps of obtaining predecessor nodes and adding predecessor nodes that meet the preset conditions to the path stack are continued for the current node until the predecessor node of the top node does not meet the preset conditions or the top node of the stack is an input node. After injecting a defect, a defect marker can be added to the current path to record information such as the defect type and injection location. The reverse path starts from the output node, passes through each intermediate node (including defect type values), and reaches the traversal termination node, forming an abnormal scenario path that marks the defect injection location. This abnormal scenario path is a reverse path.

[0129] It should be noted that the defect type library predefines various defect type values, and different defect type values ​​are applicable to nodes of different data types. For example, for numeric nodes, the boundary overflow defect type value can be selected; for object nodes, the null pointer defect type value can be selected; for nodes with association constraints, the data inconsistency defect type value can be selected; and for nodes with temporal dependencies, the timing error defect type value can be selected. During the reverse search process, the defect type value is matched from the defect type library for the data type of each predecessor node, and added at the first predecessor node that meets the defect injection conditions, thereby generating a reverse path carrying a defect marker.

[0130] For example, the boundary overflow defect type is to inject boundary values ​​that exceed the normal range (such as maximum value +1, minimum value -1, infinity / small value, etc.); the null pointer defect type is to inject null values, empty strings, uninitialized references, etc.; the data inconsistency defect type is to inject values ​​that conflict with the data of associated nodes; the timing error defect type is to inject data with disordered timing (such as expired timestamps, events in reverse order, etc.).

[0131] In one embodiment, the step 103 mentioned, "performing a forward search on the directed weighted graph to search from the input node along the direction of the weighted directed edges to the output node, generating multiple forward paths," in this embodiment, is achieved through... Figure 6Steps 601 to 603 shown are implemented.

[0132] Step 601: Starting from the input node in the directed weighted graph, add the input node to the path stack. Using node importance as a heuristic function, search along the direction of the weighted directed edges to the output node. During the search, for each current node found, select the successor node whose weight of the edge connecting the current node and the successor node is not lower than a preset weight threshold. Add the selected successor nodes to the path stack in order of increasing node importance. The node importance is determined based on the criticality of the node in the business logic.

[0133] Step 602: If the search reaches the output node, a forward path is generated based on each node in the current path stack; if the path depth of the current path stack reaches the preset depth threshold, the search is stopped, and a forward path is generated based on each node in the current path stack.

[0134] Step 603: Take the untraversed input nodes in the directed weighted graph as new input nodes, and repeat the above steps until all input nodes have been traversed, generating multiple forward paths.

[0135] It should be noted that the generation of the forward path set adopts a heuristic search strategy, traversing the directed weighted graph forward from the input nodes. Taking the edge cloud planning and configuration system as an example, the directed weighted graph of this system contains multiple input nodes (such as user input nodes, business resource data nodes, and customer resource data nodes). The following forward heuristic depth-first search is performed on each input node in the directed weighted graph: First, starting from the input node, and using node importance as a heuristic function, the search proceeds along the weighted directed edges to the output node. Node importance is determined based on the node's criticality in the business logic and is evaluated and recorded by the NLP model during the entity analysis phase.

[0136] During the search process, for each current node found, a successor node is added to the path stack only if the weight of the weighted directed edge connecting the current node and its successor node is not lower than a preset weight threshold. For example, setting the preset weight threshold to 0.2, starting from the user input node, passing through the configuration selection node, bandwidth check node, and configuration switching node in sequence, a successor node is added to the path stack only if the weight of each connecting edge is not lower than 0.2. For instance, during the search process, for each current node found, firstly, all successor nodes whose weighted directed edge connecting the current node and its successor node is not lower than the preset weight threshold are selected; then, the selected successor nodes are pushed onto the path stack in ascending order of node importance, so that successor nodes with higher importance are at the top of the stack and are popped out for exploration first. In this way, node importance serves as a heuristic function to guide the search priority, prioritizing the exploration of key business paths.

[0137] When the search reaches the output node, a forward path is generated based on the nodes in the current path stack. If the path depth of the current path stack reaches a preset depth threshold (e.g., the preset depth threshold is 5 layers) during the search process, further searching of that path is stopped, and a forward path is generated based on the nodes in the current path stack.

[0138] The above search process is performed for each input node. For example, starting from the user input node, after configuration selection, bandwidth check, and configuration switching, the path proceeds along the service restart branch and status update branch to reach the result output node, generating two forward paths; starting from the business resource data node, after bandwidth utilization analysis and formula calculation, the path reaches the detailed report node, generating one forward path; starting from the customer resource data node, after traffic analysis and edge nodes, the path reaches the data export node, generating one forward path. All forward paths obtained from searching each input node are summarized to generate multiple forward paths.

[0139] Through the above process, the system generates a set of forward paths containing normal business processes. Each forward path starts from the input node, passes through intermediate nodes, and finally reaches the output node, providing a normal process coverage basis for subsequent path fusion.

[0140] The test case generation method in this application differs significantly from existing test case design methods in several key dimensions. The following comparison illustrates this difference in four dimensions: efficiency, coverage, quality stability, and interpretability. In terms of efficiency: manual design methods rely on test engineers writing code by hand, which is inefficient and difficult to meet the needs of large-scale testing; traditional tools have a certain degree of automation, but are limited by fixed template rules and cannot cope with complex and ever-changing business scenarios; generation methods based on large language models are fast, but require a lot of time for quality verification and correction, and the actual effective output is not ideal; this application can generate test cases in batches in a short time through heuristic search and index optimization mechanisms, and no additional correction is required while ensuring quality, resulting in a significant improvement in efficiency.

[0141] In terms of coverage: manual design is limited by personal experience and time, resulting in limited coverage; traditional tools focus on normal process verification and do not adequately cover abnormal scenarios; methods based on large language models have large fluctuations in coverage and insufficient stability; this application, through a bidirectional path fusion mechanism, covers both normal processes and abnormal scenarios, and its coverage and stability are significantly better than existing technologies.

[0142] Regarding quality stability: manual design quality is highly dependent on the experience and state of the test engineer. Test cases designed by different personnel vary significantly in coverage and style, resulting in poor quality stability. The quality of traditional tools depends on the completeness of preset rules, and it is difficult to cover scenarios outside the rules, resulting in generally poor quality. The results generated by methods based on large language models are random, and the results generated multiple times for the same requirement may be inconsistent, resulting in poor quality stability. This application achieves standardized evaluation and screening of test case quality through directed weighted graph modeling and quantitative scoring mechanism, resulting in stable and reliable generated results.

[0143] Regarding interpretability: Although manually designed test cases are based on requirements documents, there are discrepancies in understanding among different people, making traceability difficult; test paths generated by traditional tools and methods based on large language models lack explicit logical traceability, making it difficult for test engineers to understand the generation logic of test cases, which poses a challenge in compliance audit scenarios; This invention achieves full interpretability by using explicit causal relationship modeling, so that each test path can be traced back to nodes and edges in a directed weighted graph.

[0144] Based on the above comparison with existing technologies, this application has the following core advantages: High efficiency: This application employs a heuristic search strategy, prioritizing the exploration of critical paths and avoiding exhaustive search of all possible path combinations, significantly reducing the search space. Simultaneously, it optimizes the path matching process through an index structure, greatly improving path matching efficiency. Compared to the efficiency of approximately 10 test cases per day through manual design, this application can generate over 100 test cases per day, achieving an efficiency improvement of more than tenfold.

[0145] Comprehensiveness: This application employs a bidirectional path fusion mechanism. On one hand, it covers normal business processes through forward search; on the other hand, it covers abnormal scenarios through reverse search and injection of defect type values. The fusion of these two approaches generates a fused path that includes both normal processes and abnormal scenarios. Compared to existing methods that focus on verifying normal processes, resulting in insufficient coverage of abnormal scenarios, this application achieves a test coverage rate of over 95%, significantly improving the comprehensiveness of the test.

[0146] Stability: This application explicitly models the causal, temporal, and constraint relationships of business logic by constructing a directed weighted graph, and combines a quantitative scoring model to conduct a multi-dimensional comprehensive evaluation of each fusion path, making the quality of test cases quantifiable and traceable, thus avoiding the quality fluctuation problems caused by manual design relying on experience, traditional tools relying on rule completeness, and large language models relying on training data quality.

[0147] Explainability: This application uses explicit causal relationship modeling, so that each test path can be traced back to the corresponding node sequence and edge weights in the directed weighted graph. Test engineers can clearly understand the generation logic of each test case and the business scenarios it covers, thus meeting the compliance audit requirements for test case traceability.

[0148] It should be noted that although the operations of the method of the present invention are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed to achieve the desired result. On the contrary, the steps depicted in the flowchart may be performed in a different order. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0149] The following is for reference. Figure 7 It shows a schematic diagram of the structure of a computer system 700 suitable for implementing terminal devices or servers in the embodiments of this application.

[0150] like Figure 7 As shown, the computer system 700 includes a central processing unit (CPU) 701, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 702 or programs loaded from storage section 708 into random access memory (RAM) 703. The RAM 703 also stores various programs and data required for the operation of the system 700. The CPU 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0151] The following components are connected to the I / O interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN card, modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the I / O interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 710 as needed so that computer programs read from it can be installed into the storage section 708 as needed.

[0152] In particular, according to embodiments of this disclosure, the above references Figure 1 The described process can be implemented as a computer software program. For example, embodiments of this disclosure include a computer program product comprising a computer program tangibly embodied on a machine-readable medium, the computer program containing instructions for performing... Figure 1 The program code for the method. In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 709, and / or installed from the removable medium 711.

[0153] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0154] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0155] The units or modules described in the embodiments of this application can be implemented in software or hardware. The described units or modules can also be located in a processor. The names of these units or modules do not, in certain circumstances, constitute a limitation on the unit or module itself.

[0156] On the other hand, this application also provides a computer-readable storage medium, which may be included in the computer device described in the above embodiments, or may exist independently and not assembled into the computer device. The aforementioned computer-readable storage medium stores one or more programs that, when used by one or more processors, execute the methods described in this application. For example, it may execute... Figure 1 The steps of the method shown are as follows.

[0157] This application provides a computer program product including instructions that, when executed, cause the method described in this application to be performed. For example, it can execute... Figure 1 The steps of the method shown are as follows.

[0158] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0159] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the inventive concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A test case generation method based on weighted graph dual-path fusion, characterized in that, The method includes: Extract an entity list and relation triples from the requirements document. The entity list contains the entity identifier, entity name, and entity type of each entity. The entity type includes input type and output type. The relation triples include the source entity identifier, relation type, and target entity identifier. A directed weighted graph is constructed based on the entity list and the relation triples. The directed weighted graph contains multiple nodes and weighted directed edges connecting the nodes. Each node corresponds to one entity. The weighted directed edges represent the relationships between entities. The weight of each weighted directed edge is determined based on the frequency of the relationship in the requirements document, the conditional probability of the target entity occurring given the occurrence of the source entity, and the criticality of the target node in the business logic. A forward search is performed on the directed weighted graph to search from the input node along the direction of the weighted directed edges to the output node, generating multiple forward paths; a reverse search is performed on the directed weighted graph to traverse from the output node along the reverse direction of the weighted directed edges, adding defect type values ​​according to predefined defect types during the traversal, generating multiple reverse paths; the input node is the node corresponding to the entity with the input type, and the output node is the node corresponding to the entity with the output type. The multiple forward paths are matched with the multiple reverse paths. Based on the matching results, each reverse path is merged with the matching forward path to obtain multiple merged paths. The multiple merged paths are prioritized and test case sets are generated based on the prioritized merged paths. Specifically, the reverse search of the directed weighted graph involves traversing from the output node along the reverse direction of the weighted directed edges, adding defect type values ​​according to predefined defect types during the traversal, and generating multiple reverse paths, including: Starting from the output node in the directed weighted graph, a path stack is created and the output node is added to the path stack as the starting node to obtain all the predecessor nodes of the output node; For each predecessor node, if the predecessor node meets the preset conditions, the predecessor node is added to the path stack and marked as visited; the preset conditions include that the predecessor node has not been visited, the current path depth has not exceeded the preset depth threshold, and the weight of the weighted directed edge connecting the top node of the path stack and the predecessor node is not lower than the preset weight threshold. For each predecessor node added to the path stack, a defect type value is matched from a predefined defect type library according to the data type of the predecessor node. The matched defect type value is added to the first predecessor node that is successfully matched and has not been added before, and the matching of subsequent predecessor nodes is stopped. The top node of the current path stack is taken as the current node, and the steps of obtaining predecessor nodes and adding predecessor nodes that meet the preset conditions to the path stack are continued for the current node until the predecessor node of the top node does not meet the preset conditions or the top node is an input node. The reverse path is generated based on the predecessor node with the added defect type value and each node in the path stack. The untraversed output nodes in the directed weighted graph are taken as new output nodes. The above steps are repeated until all output nodes are traversed. All generated reverse paths are deduplicated to obtain the multiple reverse paths.

2. The method according to claim 1, characterized in that, The weights of the weighted directed edges are determined based on the frequency of the relationship in the requirements document, the conditional probability of the target entity occurring given the occurrence of the source entity, and the criticality of the target node in the business logic, including: The frequency of the relationship in the requirement document is exponentially calculated by a first power, the conditional probability of the target entity occurring given the occurrence of the source entity is exponentially calculated by a second power, and the criticality of the target node in the business logic is exponentially calculated by a third power; then the results of each power operation are multiplied together to obtain the weight of the weighted directed edge.

3. The method according to claim 1, characterized in that, The step of matching the multiple forward paths with the multiple reverse paths, and then merging each reverse path with the matched forward path based on the matching results to obtain multiple merged paths, includes: An inverted index is established, which records the mapping relationship between node identifiers and the forward path containing the node corresponding to the node identifier; Based on the inverted index and the nodes contained in each of the reverse paths, determine the set of candidate forward paths corresponding to each of the reverse paths; For each of the reverse paths, the matching degree between the reverse path and each candidate forward path in the corresponding candidate forward path set is determined. The candidate forward paths with matching degrees greater than a preset matching degree threshold are merged with the reverse paths to obtain the multiple fused paths.

4. The method according to claim 3, characterized in that, Determining the matching degree between the reverse path and each candidate forward path in the corresponding candidate forward path set includes: For each candidate forward path in the candidate forward path set, determine the number of nodes with common nodes from the nodes contained in the candidate forward path and the nodes contained in the reverse path. The maximum number of nodes in the candidate forward path and the maximum number of nodes in the candidate reverse path is determined, and the ratio of the number of nodes to the maximum number of nodes is determined as the matching degree.

5. The method according to claim 3, characterized in that, The step of prioritizing the multiple fusion paths and generating a test case set based on the prioritized fusion paths includes: The multiple fusion paths are comprehensively scored based on the matching degree, coverage, defect coverage value, and complexity to obtain multiple path scores; the coverage rate is the proportion of the number of nodes included in the fusion path to the total number of nodes in the directed weighted graph; the defect coverage value is determined based on whether the fusion path contains defect type values; and the complexity is determined based on the path length of the fusion path. The multiple fusion paths are sorted in descending order according to the multiple path scores. The first K fusion paths in the sorted fusion paths are determined as the highest priority core paths, the (K+1)th to (3K)th fusion paths are determined as high priority important paths, the (3K+1)th to (6K)th fusion paths are determined as medium priority general paths, and the (6K+1)th to the last fusion path are determined as low priority edge paths; K is an integer greater than 0. The multiple fusion paths are transformed into structured test cases, each test case containing test steps, expected results, priorities, and coverage, thus generating the test case set.

6. The method according to claim 5, characterized in that, The multiple fusion paths are comprehensively scored based on matching degree, coverage, defect coverage value, and complexity to obtain multiple path scores, including: The path score of the fusion path is obtained by weighting and summing the matching degree, coverage, defect coverage value, and complexity of the fusion path, as well as the weights of the matching degree, coverage, defect coverage value, and complexity; wherein the weights of the matching degree, coverage, and defect coverage value are all positive, and the weight of complexity is negative.

7. The method according to claim 1, characterized in that, The forward search is performed on the directed weighted graph to search from the input node along the direction of the weighted directed edge to the output node, generating multiple forward paths, including: Starting from the input node in the directed weighted graph, the input node is added to the path stack. Using node importance as a heuristic function, the search proceeds along the direction of the weighted directed edges to the output node. During the search, for each current node found, successor nodes whose weights of the edges connecting the current node and its successor node are not lower than a preset weight threshold are selected. The selected successor nodes are then added to the path stack in ascending order of node importance. The node importance is determined based on the node's criticality in the business logic. If the search reaches the output node, a forward path is generated based on each node in the current path stack; if the path depth of the current path stack reaches a preset depth threshold, the search stops, and a forward path is generated based on each node in the current path stack. The untraversed input nodes in the directed weighted graph are used as new input nodes, and the above steps are repeated until all input nodes are traversed, generating the multiple forward paths.

8. A computer device, comprising a processor, a memory, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 7.

9. A computer program product, characterized in that, The computer program product includes instructions that, when executed, cause the method as described in any one of claims 1 to 7 to be implemented.

Images