A test case intelligent generation method and system based on a dynamic knowledge graph

Abstract

The application relates to the technical field of software testing and artificial intelligence, in particular to a test case intelligent generation method and system based on a dynamic knowledge graph, which comprises the following steps: collecting multi-source data and constructing an initial graph; capturing modification information corresponding to system version iteration, and triggering incremental expansion of the initial graph based on the modification information to obtain a real-time graph evolved dynamically; obtaining test requirements and discovering a whole-chain path in the real-time graph through graph traversal; analyzing coverage gaps and node risks in the whole-chain path and screening optimal path combinations based on reinforcement learning; generating test cases according to the optimal path combinations and corresponding parameter information; obtaining case execution results to extract execution indexes, associating defects based on the execution indexes, and optimizing path-based defect generation algorithms to adjust graph traversal weights to realize closed-loop optimization. The application has the effect of efficiently coping with dynamic changes of complex systems.

Description

Technical Field

[0001] This application relates to the technical fields of software testing and artificial intelligence, and in particular to a method and system for intelligent generation of test cases based on dynamic knowledge graphs. Background Technology

[0002] Traditional software testing primarily relies on manually writing test cases, which suffers from low efficiency, insufficient coverage, and difficulty in handling dynamic changes in complex systems. In existing technologies, knowledge graphs have been introduced into the testing field to improve automation, such as retrieving similar test cases through static graphs (e.g., test case reuse in the financial sector). However, these methods can only handle existing historical requirements and cannot effectively adapt to new or dynamically changing needs. Furthermore, solutions based on pure rules or semantic matching (such as relying on keyword segmentation and fixed templates to generate test cases) lack real-time reasoning capabilities regarding the system's runtime state and cross-module dependencies, resulting in coarse-grained test case coverage and a high rate of missing boundary scenarios.

[0003] The technical implementations most similar to this invention mainly fall into two categories:

[0004] 1. Test case recommendation based on static knowledge graph: Test requirements are processed through word segmentation, and query statements are generated by matching them with pre-defined industry database entities. Test cases are then retrieved from the knowledge graph. Its limitations lie in the fact that the knowledge graph is statically constructed, making it impossible to update node relationships in real time based on system iterations. Furthermore, it relies on a predefined industry dictionary, making it difficult to generalize to cross-domain scenarios.

[0005] 2. Knowledge Graph and Large Model Fusion Generation: Features are extracted and interface test cases are generated through neighborhood matrix fusion (low-order and high-order). While this method improves the diversity of test cases, it does not solve the problem of knowledge graph evolution in dynamic environments. For example, when the system version is updated, the knowledge graph needs to be manually reconstructed, and it lacks a closed-loop optimization mechanism for test execution feedback.

[0006] These similar solutions all focus on static knowledge reuse or offline generation, failing to achieve dynamic adjustment and self-optimization of the knowledge graph as the system changes, thus limiting their practicality in agile development. Summary of the Invention

[0007] To efficiently respond to the dynamic changes of complex systems, this application provides a method and system for intelligent generation of test cases based on dynamic knowledge graphs.

[0008] Firstly, this application provides a method for intelligently generating test cases based on dynamic knowledge graphs, employing the following technical solution:

[0009] A test case intelligent generation method based on dynamic knowledge graph includes the following steps:

[0010] Collect multi-source data and construct an initial graph, wherein nodes in the initial graph represent test entities and edges represent relationships;

[0011] Capture the modification information corresponding to the system version iteration, and trigger incremental expansion of the initial map based on the modification information to obtain a dynamically evolving real-time map;

[0012] The test requirements are obtained and the full chain path in the real-time graph is discovered through graph traversal. The coverage gaps and node risks in the full chain path are analyzed and the optimal path combination is selected based on reinforcement learning.

[0013] Test cases are generated based on the optimal path combination and corresponding parameter information;

[0014] The execution results of test cases are obtained to extract execution metrics. Defects are associated based on the execution metrics. The path-based defect generation algorithm is optimized to adjust the graph traversal weights to achieve closed-loop optimization.

[0015] In some embodiments, capturing modification information corresponding to system version iterations includes the following steps:

[0016] Monitor commit records based on version control hooks, extract version metadata from requirement documents, and detect API interface changes;

[0017] Feature inconsistency detection is performed, and system version iterations are captured when one or more detection criteria are met. The detection criteria include inconsistencies between API interface document version number and code annotation, inconsistencies between functional description in requirement document and code comments, and mismatch between schema version and entity class definition.

[0018] In some embodiments, the incremental expansion of the initial map is triggered based on the modified information to obtain a dynamically evolving real-time map, including the following steps:

[0019] When features are inconsistent, the abstract syntax tree is invoked to perform code difference analysis to generate change information;

[0020] The propagation path corresponding to the change information is analyzed by control flow analysis, the affected data dependencies are analyzed by data flow analysis, and the scope of the change is assessed based on the propagation path and the data dependencies.

[0021] Based on the change information, the change type is obtained, and based on the change type, the corresponding update strategy is matched to incrementally expand the initial graph within the change range. The incremental expansion includes node update, edge update, and weight update.

[0022] In some embodiments, the process of obtaining test requirements and discovering full-chain paths in the real-time graph through graph traversal, analyzing coverage gaps and node risks in the full-chain paths, and selecting the optimal path combination based on reinforcement learning includes the following steps:

[0023] Based on the test requirements, target nodes are mapped and constraints are extracted. All reachable paths are traversed to cover the main process and abnormal processes to obtain the full chain path.

[0024] Calculate the measured path coverage and measured node coverage in the entire chain path, and generate path priority by combining the defect rate corresponding to each node;

[0025] Based on the reinforcement learning, the path priorities are selected to generate corresponding test cases, wherein high path priority is characterized by low coverage gaps and high-risk nodes.

[0026] In some embodiments, test cases are generated based on the optimal path combination and corresponding parameter information, including the following steps:

[0027] The number of function points, the number of parameters, and the business rule dependencies in the optimal path combination are obtained to determine the scenario complexity, which includes simple, medium, and complex scenarios.

[0028] Based on the scenario complexity, a corresponding parameterized matrix generation method is generated, and the test cases are obtained based on the parameterized matrix generation method. The parameterized matrix generation method includes the equivalence partitioning method, the pairwise combination method, and the orthogonal experiment method. The parameterized test matrix includes test case steps, expected results, and associated test data.

[0029] In some embodiments, the process involves obtaining test case execution results to extract execution metrics, performing defect association based on the execution metrics, and optimizing the path-based defect generation algorithm to adjust graph traversal weights to achieve closed-loop optimization, including the following steps:

[0030] The defects are abstracted into a graph pattern, and associated edges are added;

[0031] Identify the reasons for uncovered paths and supplement graph associations or adjust traversal strategies;

[0032] The traversal weights corresponding to each node are adjusted based on defect distribution, code coverage, defect detection rate, and a genetic algorithm.

[0033] In some embodiments, the weights corresponding to each node are adjusted based on defect distribution, code coverage, defect detection rate, and a genetic algorithm, including the following steps:

[0034] A chromosome coding design is performed, wherein each chromosome is represented as one of the aforementioned pathways;

[0035] The coverage score, defect detection score, and execution cost score are calculated separately, and a fitness function is generated by combining them with preset weights.

[0036] The weight combination is dynamically adjusted by acquiring test data from several historical tests.

[0037] Genetic operations including selection, crossover, and mutation are performed respectively. When the termination condition is met, the iteration stops and the optimal path selection scheme and the traversal weight adjustment result are output.

[0038] In some embodiments, the following steps are also included:

[0039] When a new business request is received, the new business request is parsed in a structured manner to obtain the new request data;

[0040] Based on the newly added demand data, at least one similar scenario is retrieved from the real-time graph;

[0041] Test cases corresponding to the new business requirements are generated based on the new requirement data and the similar scenarios.

[0042] In some embodiments, the following steps are also included:

[0043] If the test requirement corresponds to interface testing, then define multiple interface entities and the relationships between the entities;

[0044] The strength of the association between any two interfaces is calculated based on a preset scoring rule to obtain a relationship score;

[0045] Based on the relationship scores, a low-order neighborhood matrix reflecting the strength of direct associations between the interfaces and a high-order neighborhood matrix reflecting the strength of indirect associations are constructed respectively.

[0046] The low-order neighborhood matrix and the high-order neighborhood matrix are weighted and fused to obtain a fusion matrix, and feature embedding vectors corresponding to each interface are generated based on the fusion matrix.

[0047] Based on the feature embedding vector, test cases for the interface can be generated.

[0048] Secondly, this application provides a test case intelligent generation system based on dynamic knowledge graphs, which adopts the following technical solution:

[0049] A test case intelligent generation system based on dynamic knowledge graphs, used to implement the above method, specifically includes:

[0050] The data acquisition layer is used to collect data from multiple sources;

[0051] The knowledge graph engine is used to construct an initial graph based on the multi-source data, wherein the nodes in the initial graph represent test entities and the edges represent relationships. It is also used to capture the modification information corresponding to system version iterations and trigger incremental expansion of the initial graph based on the modification information to obtain a dynamically evolving real-time graph.

[0052] The core layer for test case generation is used to obtain test requirements and discover the full chain path in the real-time graph through graph traversal, analyze the coverage gaps and node risks in the full chain path, and select the optimal path combination based on reinforcement learning to generate test cases.

[0053] The feedback optimization layer is used to obtain the execution results of test cases to extract execution metrics, perform defect association based on the execution metrics, and optimize the path-based defect generation algorithm to adjust the graph traversal weights to achieve closed-loop optimization.

[0054] The technical solutions provided by the embodiments of this application have the following technical effects:

[0055] 1. Dynamic Adaptability and Improved Coverage: Traditional methods based on static knowledge graphs cannot effectively handle new or changed requirements during software iterations, leading to insufficient test coverage. This invention, through an incremental update mechanism, enables the knowledge graph to respond in real time to system changes (such as adding APIs or modifying business rules), automatically identifying the scope of impact and updating node relationships. Combined with graph traversal algorithms such as Depth-First Search (DFS), the system can automatically discover complex business process paths and exception handling processes, thereby achieving multi-dimensional coverage calculation and optimization of nodes, edges, and paths, effectively solving the problem that traditional methods cannot guarantee coverage of all functional paths.

[0056] 2. Intelligent Reasoning and Generation Efficiency: This invention transcends generation methods that rely on fixed templates or pure rule matching, introducing intelligent reasoning based on graph structures. The system can utilize reinforcement learning models to prioritize the generation of test cases for high-risk areas based on historical defect data, and automatically derive parameterized test matrices simulating complex scenarios. This significantly improves testing efficiency and facilitates the optimized allocation of test resources.

[0057] 3. Closed-Loop Optimization and Knowledge Accumulation: Unlike solutions that generate test cases all at once, this invention constructs a closed-loop learning mechanism of "execution-feedback-optimization." The execution results of test cases (such as code coverage and defect detection rate) are fed back to the system to adjust the graph traversal strategy and optimize the generation algorithm. This process enables the system to continuously learn, accumulating "experience" from real-world testing scenarios, making the generated test cases increasingly accurate. This effectively promotes the accumulation and reuse of testing knowledge, thereby reducing maintenance costs caused by frequent changes in requirements.

[0058] In summary, this invention upgrades the knowledge graph from a static reference library to a dynamic, reasoning-enabled, and learning-capable core engine, achieving a qualitative leap in test case generation from "automation" to "intelligence," and providing strong support for ensuring the quality of complex software systems. Attached Figure Description

[0059] Figure 1 This is a schematic diagram illustrating the steps of a test case intelligent generation method based on dynamic knowledge graphs provided in an embodiment of this application.

[0060] Figure 2 This is a flowchart of the dynamic map construction and updating process in the embodiments of this application.

[0061] Figure 3 This is the working logic diagram of the test cases generated in the embodiments of this application.

[0062] Figure 4 This is a logic block diagram of the closed-loop optimization mechanism in the embodiments of this application.

[0063] Figure 5 This is a schematic diagram of a test case intelligent generation system based on dynamic knowledge graph provided in an embodiment of this application. Detailed Implementation

[0064] To better understand the purpose, technical solutions, and advantages of this application, it has been described and illustrated below with reference to the accompanying drawings and embodiments. However, those skilled in the art should understand that this application can be implemented without these details. In some cases, to avoid obscuring various aspects of this application due to unnecessary description, well-known methods, processes, systems, components, and / or circuits already described at a higher level will not be elaborated upon. It will be apparent to those skilled in the art that various modifications can be made to the embodiments disclosed in this application, and the general principles defined in this application can be applied to other embodiments and application scenarios without departing from the principles and scope of this application. Therefore, this application is not limited to the illustrated embodiments, but conforms to the broadest scope consistent with the scope of protection claimed in this application.

[0065] It should be noted that the descriptions of these embodiments are for the purpose of aiding understanding the present invention, but do not constitute a limitation thereof. Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0066] In the description of this application, "several" means one or more, "more than" means two or more, "greater than," "less than," and "exceeding" are understood to exclude the stated number, while "above," "below," and "within" are understood to include the stated number. The use of "first" and "second" in the description is merely for distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the order of the indicated technical features.

[0067] In the description of this application, the terms "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any one or more embodiments or examples.

[0068] like Figure 1 As shown in the figure, this application discloses a method for intelligent generation of test cases based on dynamic knowledge graphs, including the following steps:

[0069] S100: Collect multi-source data and construct an initial graph, where nodes in the initial graph represent test entities and edges represent relationships.

[0070] First, it is necessary to extract various types of multi-source data from requirements documents, code repositories, historical defect repositories, and runtime logs, such as feature points, interface parameters, and business rules.

[0071] Specifically, there are four core data sources:

[0072] Requirements documents: These include natural language description documents such as Product Requirements Documents (RPDs) and functional specifications.

[0073] Code repository: Access source code (Java, Python, etc.) and interface definition files (Swagger, OpenAPI) through version control tools such as Git;

[0074] Historical Defect Database: Connects with defect management tools such as Jira and Bugzilla to obtain historical bug records, defect types, and fixes;

[0075] Runtime logs: collect interface call logs, exception stack information, and user operation traces during software operation.

[0076] At the same time, corresponding data extraction and structuring operations are performed for different data sources;

[0077] For the requirements document, NLP technology (entity recognition, relation extraction) is used to extract functional points (such as "user login" and "order payment"), business rules (such as "gold members can stack coupons"), and constraints (such as "payment amount is greater than or equal to 0").

[0078] For code files, extract method call chains, interface parameters (name, type, default value), and module dependencies (such as module A calling module B's interface) using static code analysis tools.

[0079] For defect data, extract the functional modules, triggering conditions, and scope of impact associated with the defect in a structured manner (e.g., "payment interface exceeded, causing order generation failure").

[0080] For the runtime logs, parse the interface request parameters, response status codes, and process execution paths to extract dynamic runtime status information.

[0081] To construct an initial graph based on multi-source data, data fusion is first performed to deduplicatize and normalize the collected structured data (e.g., standardizing interface name formats and module classifications). Then, graph modeling is performed to define the types of nodes and edges. Nodes represent test entities, such as functional modules ("user module", "payment module"), data objects (e.g., "order", "coupon"), interfaces (e.g., " / api / pay"), and constraints (e.g., inventory greater than n). Edges represent relationships, such as dependencies ("order generation depends on successful payment"), call order (e.g., "customer login - add product"), and containment relationships (e.g., "payment interface includes fingerprint verification parameters").

[0082] The merged entity-relationship data is stored in a graph database as an initial knowledge graph, forming a structured semantic model for the software system.

[0083] S200 captures the modification information corresponding to system version iterations and triggers incremental expansion of the initial map based on the modification information to obtain a dynamically evolving real-time map.

[0084] The graph responds in real time to system changes (such as adding APIs or modifying business rules) through an incremental update mechanism. By monitoring the modifications corresponding to version changes, it dynamically updates the target nodes and / or target edges and / or target weights within the target scope in real time.

[0085] S300 obtains test requirements and discovers the full-chain path in the real-time graph through graph traversal. It analyzes the coverage gaps and node risks in the full-chain path and selects the optimal path combination based on reinforcement learning.

[0086] S400 generates test cases based on the optimal path combination and corresponding parameter information.

[0087] Based on the user's input test requirements, NLP technology is used to map them to target nodes in the graph. Through full-link path discovery and reinforcement learning, the paths to be tested are sorted by priority based on conditions such as coverage and risk. When generating test cases, test paths with high risk and low coverage are generated first.

[0088] S500 obtains test case execution results to extract execution metrics, performs defect association based on execution metrics, and optimizes the path-based defect generation algorithm to adjust graph traversal weights to achieve closed-loop optimization.

[0089] Collect test execution results, provide feedback data analysis and graph optimization to drive the graph to self-correct, dynamically adjust test path selection strategies and graph traversal weights, so that subsequent test case generation focuses more on high-value weaknesses, while balancing coverage completeness and execution efficiency, forming a closed loop of execution-feedback-optimization.

[0090] Based on the above, the main technical points of this application are:

[0091] This method enables knowledge graphs to perceive software changes and evolve automatically. It includes: incremental update algorithms that extract test entities and relationships in real time from multi-source data such as codebases, requirements documents, and defect databases; and mechanisms that automatically identify the scope of change impact and dynamically update graph nodes and associated edges when the system iterates. This technology ensures that the graph is synchronized with the software state, overcomes the lag of static graphs, and is the cornerstone for achieving high test coverage.

[0092] This document describes the specific algorithmic implementation for intelligent path discovery and test logic derivation using graph structures. It covers: methods for automatically discovering end-to-end business process paths and exception handling processes based on graph traversal algorithms; and strategies for prioritizing the generation of test cases for high-risk areas based on node attributes, combined with reinforcement learning models. Its innovation lies in upgrading test generation from "keyword matching" to "semantic relationship reasoning," effectively generating test cases that cover boundary conditions and complex scenarios.

[0093] The system employs a continuous improvement "execution-feedback-optimization" closed-loop process. This mechanism collects test execution results (such as code coverage and defect detection rate) and correlates them with corresponding nodes in the knowledge graph to quantitatively evaluate test effectiveness and generate optimization suggestions. Furthermore, based on this feedback data, the system can automatically adjust its knowledge graph traversal strategy and test case generation parameters, possessing the ability to continuously learn from real-world testing scenarios and constantly improve the accuracy of generated test cases.

[0094] Figure 2 This application demonstrates the dynamic evolution of the knowledge graph. The system first constructs an initial graph through multi-source data parsing (NLP processing of requirement documents, static code analysis to extract call relationships). In the real-time update mechanism, when the system version iterates, the change-aware module captures modifications (such as the addition of a new functional module F) and triggers incremental expansion of the initial graph. A difference comparison algorithm identifies the scope of the change's impact, automatically adding nodes (F) and associated edges (such as the dependency relationship between F and existing module A). Simultaneously, test execution feedback (such as defect distribution data) is transformed into graph attributes (such as node risk weights), optimizing the priority of subsequent test case generation. This process ensures that the graph is always synchronized with the software system state, overcoming the limitation of static graphs in handling new requirements.

[0095] Specifically,

[0096] In other embodiments, capturing modification information corresponding to system version iterations includes the following steps:

[0097] S210 monitors commit records based on version control hooks, extracts version metadata from requirement documents, and detects API interface changes.

[0098] Git hooks are used to monitor commit history in the code repository. A commit is a code submission message that includes the author, time, list of changed files, and commit message. When a developer commits code, the hook script is automatically triggered to extract the paths of changed files and keywords from the commit message (such as "add fingerprint payment parameters" or "fix inventory calibration logic").

[0099] A document parser is used to extract version metadata from the requirements document. This parser integrates multi-format document parsing tools, allows configuration of the requirements document storage path monitoring, and sets rules for triggering parsing based on changes in the document's modification timestamp. When the requirements document is modified and saved, the document parser automatically starts to extract the document's version source data, uses NLP technology to extract the functional description text, and stores both the version and functional description files together.

[0100] The API monitor detects changes to the interface definition by scanning the differences between the current interface information and historical versions. If a difference is found, the full characteristics of the current interface are extracted.

[0101] S211, perform feature inconsistency detection. When one or more detection criteria are met, the system version iteration is captured. The detection criteria include inconsistency between API interface document version number and code annotation, inconsistency between functional description in requirement document and code comments, and mismatch between schema version and entity class definition.

[0102] The system uses preset feature inconsistency detection criteria to determine whether there are modifications due to version iteration. The feature inconsistency detection criteria include the following points, and a version iteration is considered to have occurred if any one or more of them are met:

[0103] When the API documentation version number (e.g., V1.2.3) differs from the `@Version` annotation in the code implementation, this rule often corresponds to the addition / deletion / modification of API parameters or changes in response format. Specifically,

[0104] Extract API features from the code implementation, parse the modified code file using static code analysis tools, and extract interface-related annotations; extract the URL, version number, and parameter list of the same interface from the documentation; if the version number does not match, the number / type of parameters does not match, or the response format does not match, it is considered that the API features are inconsistent;

[0105] When there are semantic differences between the functional descriptions in the requirements document and the code method comments, this rule often corresponds to changes in method names, adjustments to call chains, modifications to business logic code, additions of new functionalities, and adjustments to business rules. Specifically,

[0106] The functional description file is processed by NLP to extract core elements. The modified code is parsed by a document parser to extract method names, conditional judgments in the method body, and module interfaces called. A semantic similarity algorithm is used to compare the "core elements of the requirement" with the "functional logic of the code".

[0107] When the Schame database version does not match the entity class definition, specifically...

[0108] The database table structure is queried, the version identifier is extracted, and the entity class is parsed using static code analysis tools to extract field names, types, and annotations. If there are "name mismatch", "type inconsistency", or "field missing" issues between the entity class fields and the database table fields, it indicates a mismatch in data structure characteristics.

[0109] In other embodiments, incremental expansion of the initial map is triggered based on modified information to obtain a dynamically evolving real-time map, including the following steps:

[0110] S220: When features are inconsistent, the abstract syntax tree is invoked to perform code difference analysis to generate change information.

[0111] When inconsistencies in features are detected, the change awareness module initiates a difference analysis, compares the old and new versions of code and documentation using AST trees, generates two abstract syntax trees, traverses the two AST trees using the TreeDiff algorithm, compares the syntax tree nodes, marks the difference nodes, and outputs the changed content (such as "Added coupon management module" and "Added fingerprint verification parameters to payment interface").

[0112] S221, analyze the propagation path of change information through control flow analysis, analyze the affected data dependencies through data flow analysis, and assess the scope of change based on the propagation path and data dependencies.

[0113] By using control flow analysis and data flow analysis, we can determine the upstream and downstream modules affected by the changes (e.g., adding a "coupon module" requires association with the "user module" and "order module").

[0114] Specifically, in control flow analysis, starting from the change node, the control flow path of the AST is traversed to identify the affected methods and code blocks. For example, if the change node is "the payment interface adds the fingerPrint parameter", the control flow analysis finds that the parameter is called by the validateFingerPrint() method, and then depends on the doPay() method. Therefore, validateFingerPrint() and doPay() are determined to be the affected methods.

[0115] In data flow analysis, the data flow of variables / parameters corresponding to the changed nodes is tracked. For example, the fingerPrint parameter is passed from the doPay() method, validated by validateFingerPrint(), stored in the payRecord data object, and then written to the pay_log table in the database. The "payRecord object and pay_log table" are determined to be the affected data carriers.

[0116] Finally, graph analysis is used to expand the scope of influence based on the project's method call relationship graph (pre-generated). For example, the doPay() method is called by orderService.createOrder(), and orderService.createOrder() is called by groupBuyService.createGroupOrder(), thus determining that orderService and groupBuyService are the affected modules.

[0117] Secondly, an impact report will be generated based on the changes to guide subsequent map updates. The report integrates the above analysis results and mainly includes the type of change, details of the change, scope of impact, and recommended actions.

[0118] S222: Obtain the change type based on the change information, and match the corresponding update strategy based on the change type to incrementally expand the initial graph within the change range. The incremental expansion includes node update, edge update, and weight update.

[0119] Different change types correspond to different map update strategies, such as:

[0120] When a new API interface is added, the corresponding test node and associated edge are automatically created. Specifically,

[0121] Add a new API node to the knowledge graph. Attributes include the API URL, parameter list, version number, and module. Example node:

[0122] {id:"api_pay_v2",name:" / api / pay / v2",params:["userId","orderId","fingerPrint"],module:"payment module"};

[0123] Based on the list of affected nodes, establish the relationship between the new node and related nodes:

[0124] The "containment relationship" with the module it belongs to (e.g., "Payment Module" → "Contains" → " / api / pay / v2");

[0125] The "call relationship" with dependent methods (e.g., " / api / pay / v2" → "call" → "checkStock()");

[0126] The "association" with the data object (e.g., " / api / pay / v2" → "association" → "PayRecord").

[0127] When modifying business rules, update the weights of the relevant business logic edges. Specifically,

[0128] Locate the relevant edges. In the graph, find the edges related to modifying the business rules (such as "Inventory Verification Rules" → "Threshold" → "1");

[0129] Adjust edge weights / attributes. Update edge attributes based on the changes:

[0130] If the business rule "inventory threshold ≥1" is changed to "≥2", then the threshold attribute of the edge will be updated from "1" to "2".

[0131] If the importance of a business rule increases (e.g., "the number of people required to form a group purchase is changed from 3 to 5," affecting the user payment process), then the weight of the edge will be increased from "0.6" to "0.8" (the weight affects the priority of subsequent test case generation).

[0132] This synchronously affects node attributes. It updates the "risk weight" of associated nodes (e.g., the risk weight of the inventory module node is increased from "0.3" to "0.5" due to rule changes).

[0133] When deleting a functional module, mark the relevant nodes as obsolete. Specifically,

[0134] Mark abandoned nodes. Locate the core node of the module to be deleted in the graph (such as "Old Payment Module"), add the attribute status: "abandoned" (abandoned status), and do not delete the node directly (preserve historical related data);

[0135] Freeze associated edges. Mark all associated edges of this node (such as "Old Payment Module" → "Call" → "Old Inventory Verification Interface") as frozen:"true" (frozen state), and they will no longer participate in path discovery and test case generation;

[0136] Update the test case status. Mark historical test cases associated with this module as "obsolete" and remove them from the execution plan.

[0137] The above methods enable incremental updates of the initial map in different scenarios, for example:

[0138] When the payment interface adds a "fingerprint verification" parameter, the system will:

[0139] 1. Identify newly added parameter nodes;

[0140] 2. Establish an inclusion relationship with the payment interface;

[0141] 3. Update the parameter constraints of the relevant test cases.

[0142] When the "Coupon Management" module is added to the system:

[0143] 1. Automatically create "coupon" entity nodes;

[0144] 2. Establish association edges with "users" and "orders";

[0145] 3. Generate corresponding CRUD operation test scenarios.

[0146] Figure 3The method for performing intelligent inference based on graph structures is disclosed. After inputting test requirements, Depth-First Search (DFS) is first used to discover the entire link path. For example, in an e-commerce system, starting from the "user login" node, DFS can traverse paths such as "add product - payment - generate order" to ensure coverage of the main process and abnormal processes (such as insufficient inventory). Then, the test scope is quantified by coverage calculation and combined with a reinforcement learning model to prioritize the generation of test cases for low-coverage paths.

[0147] Specifically, in some other embodiments, the process involves obtaining test requirements and discovering full-chain paths in the real-time graph through graph traversal, analyzing coverage gaps and node risks in the full-chain paths, and selecting the optimal path combination based on reinforcement learning, including the following steps:

[0148] S310 maps target nodes based on test requirements and extracts constraints, and traverses all reachable paths to cover the main process and abnormal processes to obtain the full chain path.

[0149] The system receives user-inputted testing requirements, such as verifying the entire e-commerce order process or testing coupon usage scenarios, and maps these requirements to target nodes in a graph using NLP technology. It then extracts the corresponding constraints, such as testing the differences in coupon usage between premium and regular members.

[0150] A graph traversal algorithm is used to start from the target node and traverse all reachable paths, covering both the main process and exception processes, such as:

[0151] In e-commerce ordering scenarios, the traversal path includes the main process of "user login - add product - select coupon - payment - generate order", as well as the abnormal process of "user login - add product - insufficient inventory - order failure".

[0152] Remove duplicate paths and invalid paths (such as logically contradictory paths), and retain the set of valid business paths.

[0153] S320 calculates the measured path coverage and measured node coverage in the entire chain path, and generates path priority by combining the defect rate of each node.

[0154] Coverage includes node coverage and path coverage, calculated using the following methods:

[0155] Node coverage = (Number of tested nodes / Total number of nodes) × 100%;

[0156] Path coverage = (Number of tested paths / Total number of reachable paths) × 100%.

[0157] The node coverage gap and path coverage gap can be calculated using node coverage and path coverage, respectively.

[0158] The core objective of path coverage gap analysis is to quantify whether a business process has been tested. For example, for the path "login → add to cart → payment", as long as a complete test has been performed once (regardless of whether the "payment" node has been tested by other paths), it is counted as "the number of tested paths".

[0159] The node coverage gap can correct the problem that critical nodes are not covered by any path. For example, if an e-commerce system adds a "coupon module" node, but DFS does not find a valid path containing the node, the path coverage may be at a normal level, but the node coverage will show "coupon module not tested", directly exposing the coverage blind spot.

[0160] If a node has high coverage (e.g., 90%), but the critical path associated with it has low coverage (e.g., 20%), the weight of the path coverage gap will be highlighted, and use cases for that path will still be generated first. If a node has low coverage (20%), but all associated paths have high coverage (90%), then the node coverage will trigger "supplementing new paths containing that node" (e.g., adjusting the graph traversal strategy to discover other associated paths of that node).

[0161] The defect rate is represented as the probability of a defect occurring in the past and present for a given node, and it is equal to the number of valid defects associated with that node divided by the number of related tests for that node.

[0162] The number of valid defects represents the number of defects associated with a node. It is extracted from the historical defect database and real-time test feedback and must meet two conditions: first, the defect must be clearly associated with the node, and second, the defect must be a "valid defect".

[0163] The node-related test base is characterized by the total number of test cases executed for that node.

[0164] S330 generates corresponding test cases by filtering path priorities based on reinforcement learning, where high path priority is represented by low coverage gaps and high-risk nodes.

[0165] The reward value for each path is calculated based on a reward function, and the specific formula is as follows:

[0166] Reward value = ω1 × (1 - node coverage rate) × node defect rate + ω2 × path coverage gap.

[0167] After calculating the reward value, the paths are sorted based on the value. As can be seen from the above formula, the higher the node defect rate and the larger the path coverage gap, the greater the corresponding reward value.

[0168] Therefore, the paths with low coverage and high node risk are prioritized for test case generation, for the following reasons:

[0169] High-risk nodes are directly related to core business and user interests, such as the "payment interface" of e-commerce systems and the "transfer module" of financial systems. Once these nodes have defects, they may cause serious consequences such as financial losses, user complaints, and business interruptions. The scope of their defects and the cost of repair are far greater than those of ordinary modules.

[0170] The business logic of software is implemented through the path formed by "node-edge". An uncovered path means that the business process has never been verified and there is a risk of unknown defects. Low coverage paths are mostly "edge scenarios and abnormal processes". Because they occur infrequently and are logically complex, they are easily missed by traditional manual writing or static matching schemes. However, these scenarios are often the high-frequency cause of user complaints.

[0171] Focusing on "unverified + high-value" paths, the path coverage gap represents "unverified unknown areas", and the node defect rate represents "areas with high returns after verification". The reward function that combines the two can filter out "unverified and high-value" paths, so that each generated use case has the dual value of "filling gaps + preventing risks".

[0172] In other embodiments, test cases are generated based on the optimal path combination and corresponding parameter information, including the following steps:

[0173] S331: Obtain the number of function points, the number of parameters, and the business rule dependencies in the optimal path combination to determine the scenario complexity. Scenario complexity includes simple, medium, and complex scenarios.

[0174] S332, generate corresponding parameterized matrix generation methods based on scenario complexity, obtain test cases based on parameterized matrix generation methods, wherein the parameterized matrix generation methods include equivalent partitioning method, pairwise combination method, orthogonal experiment method, and the parameterized test matrix includes test case steps, expected results and associated test data.

[0175] In simple scenarios, there is only a single functional point, no more than three parameters, and no business rule dependencies;

[0176] In medium-level scenarios, this involves a combination of 2-3 functionalities, including basic salesperson rules.

[0177] Complex scenarios involve the interaction of multiple functional points, including complex business scenario rules and exception processes.

[0178] Among them, functional points are specific business capabilities / requirements that users can perceive, such as descriptions of functions like "user login" and "coupon stacking." They are one of the important factors in classifying the complexity of a scenario. A functional point generally corresponds to multiple nodes. For example, in a simple scenario like user login, a "user login" functional point would correspond to multiple nodes such as "user," " / api / login interface," and "password verification."

[0179] The methods and strategies for generating test cases differ depending on the scenario:

[0180] In simple scenarios, since there is no interaction between functional points and no business rule dependency, the single core path under the function is first extracted based on a dynamic knowledge graph. This path is the core business process under the test requirements.

[0181] Extract key parameters and constraints of functional points from the attributes of graph nodes. For example, parameters include username and password, and constraints include that the username cannot be empty and the password length is not less than 6 characters.

[0182] To cover effective scenarios with the fewest possible parameters, test cases are directly generated using the equivalence partitioning method. Specifically, the partitioning logic is as follows:

[0183] Valid equivalence class: Normal input that meets the parameter constraints (e.g., correct username + correct password);

[0184] Invalid equivalence class: Input that violates the constraints (e.g., correct username + incorrect password);

[0185] Boundary equivalence class: critical values ​​of parameter constraints (such as a password length of 6 bits).

[0186] In medium-level scenarios, multiple functional combinations are designed, including basic business rules such as "add items to cart and checkout". In this case, DFS is still the first step to filter paths and obtain the core path and a few key branch paths corresponding to the functional combination.

[0187] Core path: Product data object - Shopping cart module - Inventory verification interface - Settlement module - Order data object.

[0188] Branch path: Inventory verification interface - Insufficient inventory - Settlement failure (This path belongs to the basic exception path because the scenario contains the business rule of "only inventory pets can be settled".)

[0189] Extract the key parameters and related business rules from the above path, such as parameters like product ID, purchase quantity, membership level, and payment method; and the business rule that purchase quantity ≤ inventory quantity.

[0190] To address the problem of multi-parameter combination explosion, this application uses Pairwise combination in its embodiments. When there are n parameters, it is not necessary to combine all of them; only combinations of all parameter pairs need to be covered. The combination logic prioritizes covering key parameter pairs that affect business rules, such as "purchase quantity + inventory status" and "membership level + payment method." Simultaneously, parameter combinations that violate business rules must be removed.

[0191] Bind paths and parameter combinations to generate corresponding structured test cases.

[0192] Complex scenarios involve interactions between multiple functionalities, as well as complex business rules and abnormal processes, such as combined scenarios involving the use of coupons, inventory verification, and payment processes.

[0193] First, a Depth-First Search (DFS) traversal is used to obtain the core path and multiple branch paths for multi-functional point interactions. Then, a reinforcement learning module outputs high-priority paths. Complex business rules are extracted from the graph, along with key parameters, such as:

[0194] Rule 1: Gold members can use 2 coupons at once, while regular members can only use 1 coupon.

[0195] Rule 2: Order amount ≥ 0 after coupons are combined;

[0196] Rule 3: A retry mechanism is triggered after payment timeout.

[0197] To address the combination explosion caused by multiple parameters and rules, an orthogonal array is used to filter the optimal coverage combination, ensuring that the value of each parameter is covered and that there are no omissions in the interaction between parameters. Finally, invalid combinations are filtered out by combining business rules.

[0198] Furthermore, based on high-risk abnormal nodes in the graph, abnormal parameter combinations are added to the matrix, such as "payment timeout = yes + retry mechanism = trigger".

[0199] Finally, in the parameter matrix obtained by the orthogonal method, each matrix combination corresponds to one test case. These are bound to high-priority paths, and the corresponding operation steps and expected results are added. The final generated test cases are as follows:

[0200] Use Case ID: UC-C-002;

[0201] Prerequisites: The user is a Gold Member, has 1 full-reduction coupon + 1 discount coupon in the account, the inventory of Product B (virtual product) is 0, and Alipay payment is supported;

[0202] Operating steps:

[0203] Log in to the e-commerce system;

[0204] Select item B (virtual item) and add it to your shopping cart;

[0205] On the checkout page, select two coupons to use together;

[0206] Select Alipay as payment and submit your order;

[0207] Simulated payment timeout (triggering timeout mechanism);

[0208] Test data: Gold membership + 2 coupons (spend more, save more + discount) + insufficient stock + Alipay + payment timeout + virtual goods;

[0209] Expected results:

[0210] The checkout process displays the message "Insufficient stock".

[0211] After payment timeout, a retry mechanism is triggered, and the page displays "Payment timed out, please pay again";

[0212] The coupon has not been redeemed and can be used again.

[0213] By using the above methods, the core algorithm, reinforcement learning participation level, number of test cases, coverage focus, and dependency graph capability size can be dynamically configured based on the complexity of different test business scenarios, so as to achieve the goal of test case generation in a targeted, intelligent, and low-redundancy manner.

[0214] Figure 4 The self-learning process disclosed in this application involves collecting metrics such as coverage and defect detection rate after test case execution and associating them with graph nodes. If certain paths are continuously uncovered or have high permission rates, the optimization algorithm adjusts the graph traversal weights and path selection strategies to guide subsequent generation to focus on weak points. Simultaneously, newly discovered defects are abstracted into graph patterns (e.g., "payment timeout" is associated with the "retry mechanism" node), enhancing the graph's reasoning capabilities through knowledge fusion. This closed loop enables the system to shift from passive generation to proactive adaptation; for example, after a version update, it automatically identifies the areas affected by the changes and generates regression test sets.

[0215] In other embodiments, the process involves obtaining test case execution results to extract execution metrics, performing defect association based on these metrics, and optimizing the path-based defect generation algorithm to adjust graph traversal weights for closed-loop optimization. This includes the following steps:

[0216] S510 abstracts defects into a graph pattern and adds associated edges.

[0217] S520 identifies the reasons for uncovered paths and supplements the graph associations or adjusts the traversal strategy.

[0218] S530 adjusts the traversal weights of each node based on defect distribution, code coverage, defect detection rate, and a genetic algorithm.

[0219] Collect test case execution results, code coverage (line coverage, branch coverage), defect detection rate (number of new bugs / number of executed test cases), and defect distribution (related graph nodes).

[0220] The newly discovered defects are abstracted into graph patterns (such as "payment timeout - retry mechanism not triggered"), and corresponding related edges are added (such as the dependency edge of "payment interface" - "retry mechanism").

[0221] The optimization process mainly involves increasing the risk traversal weight of nodes with concentrated defects and decreasing the weight of nodes with high coverage and no defects; identifying the reasons for uncovered paths, supplementing graph associations, and adjusting traversal strategies.

[0222] In other embodiments, the weights corresponding to each node are adjusted based on defect distribution, code coverage, defect detection rate, and a genetic algorithm, including the following steps:

[0223] S531 is used for chromosome coding design, where each chromosome is represented as a pathway.

[0224] S532 calculates the coverage score, defect detection score, and execution cost score respectively, and generates a fitness function by combining them with preset weights.

[0225] S533 dynamically adjusts the weight combination by acquiring test data from several historical tests.

[0226] S534 performs genetic operations including selection, crossover, and mutation. When the termination condition is met, the iteration stops and the optimal path selection scheme and traversal weight adjustment results are output.

[0227] The optimization algorithm used in this embodiment is a genetic algorithm. First, chromosome weaving is performed, with each chromosome corresponding to a path scheme. Genes are represented in binary form as "whether to select the path".

[0228] The fitness function is calculated, which is the core evaluation criterion of the genetic algorithm. In this application, it is constructed by weighting the coverage score, defect detection score and execution cost score.

[0229] The coverage score represents the weighted sum of the average coverage gaps corresponding to the paths chosen by the chromosome; the larger the gap, the higher the score. The formula is: coverage_score = Σ(coverage gap of path i × importance weight of path i) / total number of paths chosen.

[0230] The defect detection score is represented as the weighted sum of the average defect detection rates corresponding to the paths selected by the chromosome; the higher the detection rate, the higher the score. The formula is: defect_score = Σ(defect detection rate of path i × risk weight of path i) / total number of selected paths.

[0231] The execution cost score is represented as the weighted sum of the average execution costs of the paths chosen for that chromosome; the higher the cost, the lower the score. The formula is: cost_score = Σ(execution cost of path i × cost weight) / total number of paths chosen.

[0232] Each score corresponds to a weight, and the weights are not fixed values. In the initial state: α (coverage weight) = 0.4, β (defect weight) = 0.4, γ (cost weight) = 0.2.

[0233] The weighting ratio will change when one or more of the following conditions exist:

[0234] If the defect detection rate of the low-coverage path is higher than that of the high-coverage path in multiple consecutive rounds of testing, the coverage weight is increased and the defect weight is decreased.

[0235] If the execution cost of test cases on high-defect paths is too high in a certain round of testing, the cost weight will be increased.

[0236] When a new path is added after a system version iteration, the coverage weight is temporarily increased to prioritize the coverage of the new path, and then decreased after the coverage target is met.

[0237] The core of genetic operations is to "preserve high-quality chromosomes and generate new potential high-quality chromosomes" to avoid the algorithm getting trapped in local optima.

[0238] Select operation:

[0239] Based on the roulette wheel selection method, the fitness score of each chromosome is mapped to the "roulette sector area". The higher the fitness, the larger the sector area, and the higher the probability of being selected.

[0240] process:

[0241] Calculate the sum of fitness S of all chromosomes in the population;

[0242] The selection probability of each chromosome, P = the fitness of that chromosome / S;

[0243] A random number between 0 and S is generated. The chromosome that falls within a sector of a given chromosome is selected to enter the next generation of the population.

[0244] Objective: To prioritize the retention of "high-quality path combinations" with high adaptability, ensuring that the optimization direction remains unchanged.

[0245] (2) Cross operation:

[0246] Select two parent chromosomes, randomly determine a crossover point, and exchange the gene segments after the crossover point to generate two offspring chromosomes;

[0247] By fusing superior genes from the parent chromosome, new pathway combinations can be generated, expanding the search space.

[0248] (3) Mutation operation:

[0249] For each gene locus of the new generation chromosome, the gene value is randomly flipped (0→1 or 1→0) with an extremely low mutation probability (e.g., 0.05).

[0250] To avoid the population getting stuck in local optima (such as all chromosomes ignoring a low-coverage but high-value path), the algorithm must be able to explore potential high-quality combinations.

[0251] Iteration Termination and Optimal Policy Output

[0252] The iteration terminates and the optimal strategy is output when any one of the following termination conditions is met:

[0253] Iteration count target met: Preset maximum number of iterations to ensure algorithm efficiency;

[0254] Fitness convergence: If the difference in the fitness of the optimal chromosome is less than a threshold (e.g., 0.01) for three consecutive generations of population, it indicates that a stable optimal strategy has been found.

[0255] Objective achieved: The optimal path combination corresponding to the chromosome satisfies the preset objectives (such as coverage ≥ 85%, defect detection rate ≥ 20%, and execution cost ≤ 15s).

[0256] Output result:

[0257] The optimal path selection scheme guides the test generation core layer to prioritize the generation of test cases along these paths;

[0258] The graph traversal weight adjustment results increase the traversal weight of nodes in the optimal path, so that subsequent graph traversal algorithms (DFS) will prioritize traversing the paths associated with these nodes.

[0259] In other embodiments, the following steps are also included:

[0260] When S600 receives a new business request, it performs structured parsing of the new business request to obtain the new request data.

[0261] S610, based on the newly added demand data, retrieve at least one similar scenario in the real-time map.

[0262] S620 generates test cases corresponding to new business requirements based on new requirement data and similar scenarios.

[0263] The core of this solution lies in training a dedicated "test case generation model" to handle new business requirements not yet present in the knowledge graph. The main process is as follows: when a new requirement is encountered, it is first structured and analyzed using deep learning techniques. Then, similar test points or business scenarios are searched within the knowledge graph. Based on these similarities, test cases for the new requirement are derived through the generation model. The core advantage of this method lies in its powerful extrapolation and adaptability, effectively solving the fundamental problem that static knowledge graphs cannot handle entirely new business requirements. It is particularly suitable for agile development environments where business requirements change rapidly and are frequently updated.

[0264] The specific implementation method is as follows:

[0265] First, a case generation model is trained, and cross-domain historical test cases (including test case steps, parameter combinations, expected results, and associated business rules) are collected and bound to the function points, nodes, and relationships in the real-time graph to build an labeled dataset.

[0266] Semantic encoding is performed on historical test points, business scenarios, and parameter constraints in the knowledge graph to generate vector indexes. The TransE algorithm is used to convert entity-relationship-entity triples into low-dimensional vectors, which facilitates rapid calculation of similarity in the future.

[0267] The newly added business requirements based on natural language descriptions are analyzed, core elements are extracted, and structured output is performed.

[0268] Calculate the cosine similarity between the structured output results corresponding to the new business requirements and the historical scene vectors in the knowledge graph, and filter out several highly similar scenes. For example, when adding the requirement of "group ordering", similar scenes such as "multiple people pay together", "group purchase discount redemption" and "automatic refund after timeout" are retrieved. Extract the core test points of these scenes (such as "participant number boundary verification", "related rights trigger verification" and "timeout mechanism effectiveness").

[0269] The model encoder receives structured requirements and similarity points, while the decoder outputs a test case framework. The model automatically generates and populates equivalence classes and boundary value test data based on parameter constraints of similar scenarios; it extracts verification logic corresponding to associated processes from similar scenarios (e.g., refunds require simultaneous cancellation of coupons) and integrates it into test cases corresponding to new business requirements.

[0270] In other embodiments, the following steps are also included:

[0271] S700: If the test requirement corresponds to interface testing, then define multiple interfaces, entities, and the relationships between entities.

[0272] S710 calculates the strength of the association between any two interfaces based on preset scoring rules to obtain a relationship score.

[0273] S720 constructs a low-order neighborhood matrix reflecting the strength of direct association between interfaces and a high-order neighborhood matrix reflecting the strength of indirect association based on the relationship score.

[0274] S730 performs weighted fusion of the low-order and high-order neighborhood matrices to obtain a fusion matrix, and generates feature embedding vectors corresponding to each interface based on the fusion matrix.

[0275] S740, based on the feature embedding vector, guide the generation of test cases for the interface.

[0276] This solution is primarily optimized for API testing scenarios. It transforms complex entity relationships in a knowledge graph into low-order and high-order neighborhood matrices using a pre-defined relationship scoring function, mathematically representing the complex direct and indirect connections between entities. Subsequently, a specific fusion algorithm is employed to weightedly fuse neighborhood information from different levels, generating embedding vectors rich in latent features. These vectors are then used to predict API requests and generate test cases. The advantage of this solution lies in its strong ability to handle complex relationship networks, achieving a good balance between diversity and accuracy in the generated test cases, making it highly suitable for API or microservice-intensive testing scenarios.

[0277] The specific implementation steps are as follows:

[0278] First, define the interface entities, treating each API interface as a core node. Attributes include interface parameters, request methods, response formats, and dependent interfaces. Clarify the relationships between interfaces, including dependencies (interface A calls interface B), data flow transformation relationships (the output of interface A is the input of interface B), and constraints (the call to interface A must satisfy the return result of interface B).

[0279] Each interface relationship is assigned a basic weight, which is then dynamically adjusted based on historical data.

[0280] The relationship score is calculated as follows:

[0281] RelationScore(A,B)=W_base×R_type+W_dynamic×(1-1 / (1+DefectRate(A,B))).

[0282] Among them, W_base represents the basic weight of the relation type (dependency relation = 0.6, data flow relation = 0.3, constraint relation = 0.1); R_type represents the relation type identifier (existence of the relation = 1, non-existence = 0); W_dynamic represents the dynamically adjusted weight (default = 0.4); DefectRate (A,B) represents the historical defect rate when the A and B interfaces are called together (the higher the defect rate, the higher the association strength score).

[0283] The low-order neighborhood matrix is ​​a first-order matrix with a dimension equal to the total number of interfaces multiplied by the total number of interfaces, representing the direct association strength between interface A and interface B.

[0284] The higher-order neighborhood matrix is ​​a matrix of order two or higher, which represents the indirect association strength between interface A and interface C through intermediate interface B. The same applies to matrix of order three and higher. The matrix multiplication is used to capture the long-distance dependencies between interfaces.

[0285] We employ an attention mechanism for weighted fusion to automatically learn the importance weights of different matrices. The attention weights are obtained through model training, and the values ​​of the weights will vary depending on the scenario.

[0286] Example of fusion: Assume the relationship score between interface A and interface C in the first-order function is 0.52, the second-order matrix M2[A][C]=0.67×0.71≈0.47, and the third-order matrix M3[A][D]=0.67×0.71×0.45≈0.21. Then the fusion matrix [A][C]=0.5 (first weight)×0.52+0.3 (second weight)×0.47+0.2 (third weight)×0.21≈0.26+0.14+0.04=0.44.

[0287] The fused matrix is ​​subjected to feature dimensionality reduction, transforming the high-dimensional correlation features of each interface into a low-dimensional embedding vector. The vector contains information such as the strength of direct / indirect dependencies of the interfaces and the correlation of defect risks.

[0288] The core testing dimension for the prediction interface is to input embedded vectors into the classification model (such as logistic regression, lightweight CNN):

[0289] Based on the "data flow relationship features" in the vector, generate valid / invalid combinations of interface input parameters (such as "Inventory quantity of inventory verification interface = 10 (valid)" and "Inventory quantity = -5 (invalid)").

[0290] Based on the "dependency relationship feature", generate test cases for multiple interfaces in a coordinated manner (such as "calling the inventory verification interface returns 'sufficient inventory' → calling the payment interface → calling the order generation interface").

[0291] Based on "defect association characteristics", generate high-risk abnormal test cases (such as "the inventory verification interface on which the payment interface depends returns a timeout → verify the fault tolerance processing of the payment interface").

[0292] Finally, the structured output of the interface test cases includes fields such as "interface URL, request parameters, request method, dependent interface status, and expected response".

[0293] This application also discloses a test case intelligent generation system based on dynamic knowledge graphs, used to implement the above method, specifically including:

[0294] The data acquisition layer is used to collect data from multiple sources.

[0295] The knowledge graph engine is used to construct an initial graph based on multi-source data. In the initial graph, nodes represent test entities and edges represent relationships. It is also used to capture modification information corresponding to system version iterations and trigger incremental expansion of the initial graph based on the modification information to obtain a dynamically evolving real-time graph.

[0296] The core layer for test case generation is used to obtain test requirements and discover the full chain path in the real-time graph through graph traversal. It analyzes the coverage gaps and node risks in the full chain path, and selects the optimal path combination based on reinforcement learning to generate test cases.

[0297] The feedback optimization layer is used to obtain the execution results of test cases to extract execution metrics, perform defect association based on execution metrics, and optimize the path-based defect generation algorithm to adjust the graph traversal weights to achieve closed-loop optimization.

[0298] The implementation principle is as follows:

[0299] This method enables knowledge graphs to perceive software changes and evolve automatically. It includes: incremental update algorithms that extract test entities and relationships in real time from multi-source data such as codebases, requirements documents, and defect databases; and mechanisms that automatically identify the scope of change impact and dynamically update graph nodes and associated edges when the system iterates. This technology ensures that the graph is synchronized with the software state, overcomes the lag of static graphs, and is the cornerstone for achieving high test coverage.

[0300] This document describes the specific algorithmic implementation for intelligent path discovery and test logic derivation using graph structures. It covers: methods for automatically discovering end-to-end business process paths and exception handling processes based on graph traversal algorithms; and strategies for prioritizing the generation of test cases for high-risk areas based on node attributes, combined with reinforcement learning models. Its innovation lies in upgrading test generation from "keyword matching" to "semantic relationship reasoning," effectively generating test cases that cover boundary conditions and complex scenarios.

[0301] The system employs a continuous improvement "execution-feedback-optimization" closed-loop process. This mechanism collects test execution results (such as code coverage and defect detection rate) and correlates them with corresponding nodes in the knowledge graph to quantitatively evaluate test effectiveness and generate optimization suggestions. Furthermore, based on this feedback data, the system can automatically adjust its knowledge graph traversal strategy and test case generation parameters, possessing the ability to continuously learn from real-world testing scenarios and constantly improve the accuracy of generated test cases.

[0302] It should be understood that although the steps in the flowcharts in the accompanying drawings are shown sequentially as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise expressly stated herein, there is no strict order in which these steps are performed, and they may be performed in other orders.

[0303] The above are all preferred embodiments of this application and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape and principle of this application should be covered within the scope of protection of this application.

Claims

1. A method for intelligent generation of test cases based on dynamic knowledge graphs, characterized in that, Includes the following steps: Collect multi-source data and construct an initial graph, wherein nodes in the initial graph represent test entities and edges represent relationships; Based on version control hooks, commit records are monitored, version metadata of requirement documents is extracted, API interface changes are detected, modification information corresponding to system version iterations is captured, and incremental expansion of the initial graph is triggered based on the modification information to obtain a dynamically evolving real-time graph. Specifically, When features are inconsistent, the abstract syntax tree is invoked to perform code difference analysis to generate change information; The propagation path corresponding to the change information is analyzed by control flow analysis, the affected data dependencies are analyzed by data flow analysis, and the scope of the change is assessed based on the propagation path and the data dependencies. Based on the change information, the change type is obtained, and based on the change type, the corresponding update strategy is matched to incrementally expand the initial graph within the change range. The incremental expansion includes node update, edge update, and weight update. The testing requirements are obtained, and full-chain paths in the real-time graph are discovered through graph traversal. Coverage gaps and node risks within these full-chain paths are analyzed, and the optimal path combination is selected based on reinforcement learning. Specifically... Based on the test requirements, target nodes are mapped and constraints are extracted. All reachable paths are traversed to cover the main process and abnormal processes to obtain the full chain path. The measured path coverage and measured node coverage in the entire chain path are calculated, and the path priority is generated by combining the defect rate of each node. Specifically, the reward value corresponding to each path is calculated based on the reward function, combined with the node coverage rate, node defect rate and path coverage gap. The path priority is generated based on the magnitude of the reward value. The larger the reward value, the higher the path priority. Based on the reinforcement learning, the path priority is selected to generate the corresponding test cases, wherein the high path priority is characterized by low coverage gaps and high-risk nodes. Test cases are generated based on the optimal path combination and corresponding parameter information; The execution results of test cases are obtained to extract execution metrics. Defects are associated based on these metrics. The path-based defect generation algorithm is optimized to adjust graph traversal weights to achieve closed-loop optimization. Specifically, The defects are abstracted into a graph pattern, and associated edges are added; Identify the reasons for uncovered paths and supplement graph associations or adjust traversal strategies; The traversal weights corresponding to each node are adjusted based on defect distribution, code coverage, defect detection rate, and a genetic algorithm. Specifically, A chromosome coding design is performed, wherein each chromosome is represented as one of the aforementioned pathways; The coverage score, defect detection score, and execution cost score are calculated separately, and a fitness function is generated by combining them with preset weights. The weight combination is dynamically adjusted by acquiring test data from several historical tests. Genetic operations including selection, crossover, and mutation are performed respectively. When the termination condition is met, the iteration stops and the optimal path selection scheme and the traversal weight adjustment result are output.

2. The intelligent test case generation method based on dynamic knowledge graph according to claim 1, characterized in that, Capturing modification information corresponding to system version iterations includes the following steps: Feature inconsistency detection is performed, and system version iterations are captured when one or more detection criteria are met. The detection criteria include inconsistencies between API interface document version number and code annotation, inconsistencies between functional description in requirement document and code comments, and mismatch between schema version and entity class definition.

3. The intelligent test case generation method based on dynamic knowledge graph according to claim 1, characterized in that, Based on the optimal path combination and corresponding parameter information, test cases are generated, including the following steps: The number of function points, the number of parameters, and the business rule dependencies in the optimal path combination are obtained to determine the scenario complexity, which includes simple, medium, and complex scenarios. Based on the scenario complexity, a corresponding parameterized matrix generation method is generated, and the test cases are obtained based on the parameterized matrix generation method. The parameterized matrix generation method includes the equivalence partitioning method, the pairwise combination method, and the orthogonal experiment method. The parameterized matrix includes test case steps, expected results, and associated test data.

4. The intelligent test case generation method based on dynamic knowledge graph according to claim 1, characterized in that, It also includes the following steps: When a new business request is received, the new business request is parsed in a structured manner to obtain the new request data; Based on the newly added demand data, at least one similar scenario is retrieved from the graph; Test cases corresponding to the new business requirements are generated based on the new requirement data and the similar scenarios.

5. The intelligent test case generation method based on dynamic knowledge graph according to claim 1, characterized in that, It also includes the following steps: If the test requirement corresponds to interface testing, then define multiple interface entities and the relationships between the entities; The strength of the association between any two interfaces is calculated based on a preset scoring rule to obtain a relationship score; Based on the relationship scores, a low-order neighborhood matrix reflecting the strength of direct associations between the interfaces and a high-order neighborhood matrix reflecting the strength of indirect associations are constructed respectively. The low-order neighborhood matrix and the high-order neighborhood matrix are weighted and fused to obtain a fusion matrix, and feature embedding vectors corresponding to each interface are generated based on the fusion matrix. Test cases for the interface are generated based on the feature embedding vector.

6. A test case intelligent generation system based on dynamic knowledge graph, characterized in that, To implement the method as described in any one of claims 1-5, specifically comprising: The data acquisition layer is used to collect data from multiple sources; The knowledge graph engine is used to construct an initial graph based on the multi-source data, wherein the nodes in the initial graph represent test entities and the edges represent relationships. It is also used to capture the modification information corresponding to system version iterations and trigger incremental expansion of the initial graph based on the modification information to obtain a dynamically evolving real-time graph. The core layer for test case generation is used to obtain test requirements and discover the full chain path in the real-time graph through graph traversal, analyze the coverage gaps and node risks in the full chain path, and select the optimal path combination based on reinforcement learning to generate test cases. The feedback optimization layer is used to obtain the execution results of test cases to extract execution metrics, perform defect association based on the execution metrics, and optimize the path-based defect generation algorithm to adjust the graph traversal weights to achieve closed-loop optimization.

Images