A software automatic test generation method for a whole life cycle

Abstract

The application discloses a kind of software automatic test generation methods for whole life cycle, belong to software test automation technical field.The method includes: the multi-source data related to software project is parsed, initial knowledge graph is constructed, the initial knowledge graph is stored using graph database, and time stamp and version label are attached for each node and relationship;Obtain the iteration event of the software project;Based on the iteration event, the initial knowledge graph is incrementally updated, and the updated knowledge graph is obtained;According to the updated knowledge graph, test and check the function change and potential defect risk caused by this iteration, and generate feedback data package;Extract the data in the feedback data package, and adaptively optimize the updated knowledge graph.The application gets rid of the dependence on artificial preset demand, inventory case, improves test pertinence, iteration adaptability and long-term evolution ability.

Description

Technical Field

[0001] This invention belongs to the field of software testing automation and intelligence technology, specifically relating to a method for generating automated software tests throughout the entire lifecycle. Background Technology

[0002] CN119807064A discloses a knowledge graph-based intelligent review method for financial test cases, belonging to the field of financial testing. The method includes four steps: Step 1, test requirement analysis; Step 2, test case analysis; Step 3, knowledge graph construction; and Step 4, semantic matching of test requirement items and test cases. This invention's knowledge graph-based intelligent review method for financial test cases achieves efficient, accurate, and standardized test case review through automation and intelligence, reducing costs and improving system reliability. It is expected to improve the efficiency and quality of financial test case review.

[0003] The above-mentioned comparative solution CN119807064A only focuses on the post-hoc semantic review and matching of existing test requirements and existing test cases. It only conducts a secondary semantic review of the already formed test requirement text and the existing test cases that have been pre-written manually. The application prerequisites heavily rely on manual requirement decomposition and cannot independently carry out test-related work without human input. The knowledge graph constructed by the above solutions is a static, one-time construction structure. The graph entities and relationships are generated only based on the requirements and test case texts parsed in a single instance. There is no incremental update logic to adapt to software version iterations. It cannot adapt to changes in program call relationships and business processes caused by code iterations and business logic adjustments. It cannot synchronously update node and associated edge information. Long-term use of the following graph semantic structure will lead to a disconnect from the actual business architecture.

[0004] Meanwhile, the above solutions only complete bidirectional graph matching and scoring based on the cosine similarity of nodes and edges. The functions can only quantify the coverage of existing test cases to requirements and mark uncovered requirement items. They only have the ability to detect problems and do not have the technical logic to locate the business impact domain based on program code changes or automatically mine the path to be tested. They do not have the proactive ability to generate new test cases and supplement test coverage gaps. Summary of the Invention

[0005] In view of the shortcomings of the existing technology, the purpose of this invention is to provide a method for generating automated software tests throughout the entire lifecycle.

[0006] The objective of this invention is achieved through the following technical solution: a method for generating automated software tests throughout its entire lifecycle, comprising:

[0007] Analyze multi-source data related to the software project to construct an initial knowledge graph. The initial knowledge graph is stored in a graph database, and a timestamp and version tag are attached to each node and relationship.

[0008] Obtain the iteration events of the software project;

[0009] Based on the iterative events, the initial knowledge graph is incrementally updated to obtain the updated knowledge graph;

[0010] Based on the updated knowledge graph, test and verify the functional changes and potential defects caused by this iteration, and generate a feedback data package;

[0011] Data is extracted from the feedback data packet, and the updated knowledge graph is adaptively optimized.

[0012] Furthermore, the project analyzes multi-source data related to the software project to construct an initial knowledge graph. This includes analyzing multi-source data containing requirements documents, design models, source code version history, and test case libraries, using a graph data model for unified representation, and constructing an initial knowledge graph with business entities, functional modules, data flows, and control dependencies as nodes.

[0013] Furthermore, acquiring iteration events of the software project includes: integrating listeners into the development environment of the software project to monitor code commits, requirement change requests, defect fix records, and deployment pipeline status; wherein, once any modification is captured by the version control system, the listener generates a structured event and publishes the event to a message queue.

[0014] Furthermore, based on the iterative events, the initial knowledge graph is incrementally updated, including:

[0015] The impact analysis of the iterative events is performed based on the graph incremental update engine to identify the nodes and relationships in the initial knowledge graph that need to be modified.

[0016] An incremental update algorithm is used to reconstruct only the affected subgraphs, while retaining the graph structure of the unchanged parts, to obtain the updated knowledge graph;

[0017] The updated knowledge graph is then subjected to consistency verification.

[0018] Furthermore, the consistency verification includes structural consistency verification and semantic consistency verification;

[0019] The structural consistency verification is used to ensure that there are no isolated nodes in the updated subgraph;

[0020] The semantic consistency verification is used to ensure that the updated node attributes match the actual metric values ​​in the source code. When the matching degree is lower than a preset threshold, the graph incremental update engine triggers a rollback operation to restore the subgraph to the snapshot state before the update and generates an alarm log for manual intervention.

[0021] Furthermore, based on the updated knowledge graph, the functional changes and potential defect risks caused by this iteration are tested and verified, including: traversing the key business paths and data flow links associated with the changes, integrating equivalence class partitioning and boundary value analysis testing methods to construct test scenarios covering the newly added business logic, automatically generating standardized test cases containing test inputs, expected outputs, and execution steps, and connecting to the continuous integration process.

[0022] Furthermore, by traversing the key business paths and data flow links associated with the changes, and integrating equivalence class partitioning and boundary value analysis testing methods, test scenarios covering the newly added business logic are constructed. Standardized test cases containing test inputs, expected outputs, and execution steps are automatically generated, including:

[0023] Traverse the key business paths and data flow links associated with the change, trace the call chain and data flow path in reverse with the change node as the endpoint, extract the input parameter type, return value type, precondition label and read / write position of variables in the data flow of the nodes on the path, and generate a data dictionary;

[0024] Based on the data dictionary, a coverage target including path coverage, branch coverage and data flow coverage is constructed for each path to be tested. The coverage rates of the three types of coverage targets are weighted and fused as a test sufficiency score to guide the test generation engine to prioritize the coverage of high-risk paths.

[0025] For the path to be covered, the test generation engine generates candidate inputs, verifies whether the candidate inputs meet the expected path branches through symbolic simulation execution, and filters valid test inputs.

[0026] Valid test inputs are instantiated into standardized test cases, where a natural language description version and an executable script skeleton for automated execution are generated for each test case;

[0027] The standardized test cases are automatically integrated into the continuous integration pipeline, and test tasks are automatically triggered during code merging, with priority given to scheduling test cases corresponding to the deletion changes;

[0028] After the test is completed, a standardized test report is generated, which records the test case execution results, the deviation between the actual output and the expected output, and various coverage indicators. The test report and the execution log are then encapsulated into a structured feedback data package.

[0029] Furthermore, the updated knowledge graph is adaptively optimized, including: for logical paths where the test coverage is lower than the preset coverage rate or the frequency of defects is higher than the preset frequency, adjusting the weight or association strength of the corresponding node in the graph, so as to realize the self-correction and continuous optimization of the knowledge graph.

[0030] The present invention also provides an electronic device, including a memory and a processor, wherein the memory is coupled to the processor; wherein the memory is used to store program data, and the processor is used to execute the program data to implement the method.

[0031] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described thereon.

[0032] The beneficial effects of this invention are as follows:

[0033] 1. This solution uses a dynamic knowledge graph to accurately pinpoint the impact domain of iterative changes, eliminating the redundant overhead of full regression testing. The update engine completes updates based on change nodes. Figure 1 After consistency verification, test cases are generated only from the affected business paths. Targeted testing is conducted only on the addition, modification, and deletion logic, significantly reducing the scope of invalid tests, shortening the execution time of the CI pipeline, and prioritizing high-priority test cases can expose high-risk defects in advance, improving iteration and deployment efficiency.

[0034] 2. The test case generation process in this invention is fully automated. It collects path parameters based on the data dictionary, and automatically constructs test scenarios by combining equivalence class partitioning and boundary value analysis. It simultaneously outputs a text version for manual review and an executable script adapted to the framework. Testers do not need to manually sort out the call chain and write input parameters to predict the results, which reduces labor costs and ensures the complete coverage of business branches and data flows by the test cases.

[0035] 3. This invention encapsulates coverage and defect data into standardized feedback data packages, dynamically adjusts the weight of graph nodes and edge association strength based on actual business defects and coverage shortcomings, continuously optimizes the accuracy of subsequent change impact range determination, and ensures that path extraction and risk positioning remain accurate with project iteration, possessing self-adaptive and self-iterative long-term optimization capabilities.

[0036] 4. The test cases generated by this invention are automatically integrated into Jenkins and GitLab CI, bound to code merging trigger rules, and executed according to change type. High-risk deletion changes are verified first, and standardized test reports retain complete execution records, meeting the requirements for R&D audit traceability, standardizing the entry threshold for iterative testing, and reducing the risk of regression in online functions.

[0037] 5. A graph consistency verification mechanism ensures the reliability of incremental updates and avoids the risk of model distortion. It uses the L1 norm of feature vectors to calculate consistency scores, adds a minimum coefficient to avoid calculation anomalies, and automatically triggers rollback if the subgraph deviation exceeds the limit after an update. This prevents local graph modifications from causing overall business logic errors, ensuring the stability and reliability of the data source for subsequent path extraction and test case generation, and providing a trustworthy underlying data benchmark throughout the entire chain. Attached Figure Description

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

[0039] Figure 1 This is an overall flowchart of the method provided in the embodiments of the present invention;

[0040] Figure 2 This is a diagram illustrating the hierarchical architecture of a dynamic knowledge graph provided in an embodiment of the present invention.

[0041] Figure 3 This is a schematic diagram illustrating the relationships between various node sets in step 3 of this embodiment of the invention;

[0042] Figure 4 This is a flowchart illustrating the entire business execution process for step 4 of this invention.

[0043] Figure 5 This is a flowchart illustrating the upstream and downstream data interaction process in step 4 of this invention. Detailed Implementation

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

[0045] This invention provides a method for generating automated software tests throughout the entire lifecycle, which addresses the problems of low accuracy in locating the scope of change impact, high cost of manually writing test cases, inability of static knowledge graphs to adapt to business iteration updates, disconnect between test execution and knowledge optimization, and structural distortion in incremental knowledge graph updates in traditional software iterative testing.

[0046] This invention uses code change-driven incremental updates of the knowledge graph, coupled with a consistency verification mechanism, to accurately pinpoint change-related business paths. It automatically completes test scenario construction, standardized test case generation, and continuous integration pipeline adaptation. Combined with real-world test feedback data packages, it achieves autonomous iterative optimization of graph node weights and association strength. This covers the entire software testing lifecycle, from code change awareness and automated test case generation to pipeline test execution and knowledge base closed-loop self-optimization. It reduces redundant regression testing overhead and continuously improves the accuracy and completeness of subsequent version testing. The specific implementation steps are as follows:

[0047] Step 1: Analyze multi-source data related to the software project and construct an initial knowledge graph. The initial knowledge graph is stored in a graph database, and a timestamp and version tag are attached to each node and relationship.

[0048] Specifically, by parsing multi-source data such as requirement documents, design models, source code version history, and test case libraries, an initial knowledge graph is constructed with business entities, functional modules, data flows, and control dependencies as nodes. The initial knowledge graph is stored in a graph database, and each node and relationship is attached with a timestamp and version tag to record its evolution trajectory within its life cycle.

[0049] In this embodiment, the following structured information is specifically extracted from multi-source data:

[0050] For the requirements document, a hybrid extraction method combining domain dictionary and pre-trained language model (such as BERT) is adopted to identify the business entities and their attribute constraints.

[0051] For the UML design model, the class hierarchy, interface definitions, and static dependencies between components are obtained by parsing the XMI file.

[0052] For the source code, an Abstract Syntax Tree (AST) parser is used to extract metrics such as method signatures, call chains, variable read / write relationships, and cyclomatic complexity. At the same time, Git version logs are combined to parse the set of change files and commit information for each commit.

[0053] For the historical test case library, parse the assertion logic in the test scripts and map it to the method under test, and extract the existing coverage paths.

[0054] like Figure 2 As shown, after extracting multi-source data, a graph data model is used for unified representation, defining five core node types: business entities, functional modules, code methods, data flow nodes, and test cases, as well as five core relationships: CONTAINS, CALLS, FLOWS_TO, DEPENDS_ON, and TEST_COVERS.

[0055] At the storage level, Neo4j was chosen as the main graph database to support efficient relational queries and path traversal. At the same time, four-dimensional metadata tags were attached to each node and relationship: creation timestamp, last modification timestamp, version number, and change type, thus forming a time-series graph with an evolutionary trajectory.

[0056] In a further implementation, a Redis cache layer is introduced to store frequently accessed subgraph snapshots, supplemented by InfluxDB to record the historical change sequence of node attributes, supporting the tracing of the graph's complete form across any release version along the timeline. During initialization, a strategy combining batch import and incremental verification is employed. First, offline batch processing completes full parsing and graph assembly, followed by consistency checks.

[0057] Step 2: Obtain the iteration events of the software project.

[0058] Specifically, a real-time change listener is deployed to capture software iteration events, serving as a backend service for receiving data reported by all listener agents and uniformly formatting events. Listener agents are integrated into the development environment; these agents are distributed across the underlying data collection plugins of various business systems to monitor code commits, requirement change requests, defect fix records, and deployment pipeline status.

[0059] Once any modification is captured by the version control system, the listener will immediately generate a structured event message. The event message includes the scope of the change, the type of modification, the affected modules, and the associated business logic. The event will then be published to the message queue for subsequent processing by the graph incremental update engine.

[0060] For example, the version control system could be GitLab / Git, which is only responsible for managing code versions, recording commits, and merging operations.

[0061] Step 3: Based on the iterative events, incrementally update the initial knowledge graph to obtain the updated knowledge graph.

[0062] Specifically, the change events in the message queue mentioned in step 2 will trigger the graph incremental update engine. The engine first performs an impact analysis on the events and identifies the nodes and relationships in the initial knowledge graph that need to be modified.

[0063] Then, an incremental update algorithm is used to reconstruct only the affected subgraphs, preserving the unchanged parts of the graph structure. The updated graph is then updated and its logical consistency and integrity are automatically verified, thereby maintaining a high degree of consistency between the knowledge graph and the actual state of the software.

[0064] For example, the graph incremental update engine is an independent backend-driven computing service that takes standardized change events in the message queue as the only input. It integrates a change impact domain breadth-first propagation algorithm, subgraph incremental rewriting logic, and an L1 norm consistency verification module. It receives software iteration change signals pushed by the monitoring link and performs local addition, deletion, and modification operations on nodes and relationships in the induced subgraphs affected by code changes within the dynamic knowledge graph.

[0065] In this embodiment, as Figure 3 As shown, after receiving a change event, the map incremental update engine first performs an impact domain delineation. Let the set of source code files involved in the change event be... Each file Includes a collection of methods The graph incremental update engine locates the specific method node set by parsing the change line numbers in the Git diff. The nodes in this set constitute the initial seed set that influences propagation. .

[0066] The propagation of influence follows a breadth-first traversal of the dependencies in the graph, and the propagation rule is defined as follows: if a node... Dependent on nodes or Call ,but Changes will affect in the reverse direction of dependencies. .

[0067] Let the current seed set be... exist The set of neighboring nodes that expand outward after round propagation is The propagation process can then be formalized as follows: ;

[0068] in, express The union of the outgoing dependent neighbors and the incoming caller neighbors of all nodes. Represents a node The shortest path length to the initial seed set is obtained by calculating the minimum number of relational edges between two nodes in the graph. The preset influence radius threshold is dynamically adjusted based on the software's coupling degree, especially for highly coupled modules. Take the larger value, loosely coupled module Take the smaller value.

[0069] By limiting the impact of changes to prevent them from spreading indefinitely throughout the entire graph, and ensuring that both directly and indirectly dependent nodes are included in the update scope, The value of is obtained by training with historical regression defect data, so that the false negative rate and false positive rate are balanced.

[0070] After defining the influence region, the map incremental update engine updates the affected subgraphs. Implement incremental updates, among which To ultimately affect the set, This represents the induced subgraph derived from the set, containing all nodes in the set and all relations whose two ends are both in the set. The incremental update algorithm introduces a version difference mechanism to maintain a version counter for each node. Initially The counter increments each time a node is modified. ,relation Version counter Independently incremental, during updates, the engine transforms code changes in new events into a sequence of graph operation primitives, including node attribute modifications, node additions / deletions, and relationship additions / deletions. These operation primitives directly act on... Without touching any external nodes, the time complexity of this process is O(n log n). ,in The average degree of the nodes within the subgraph, since Typically much smaller than the total number of nodes in the entire graph, updates are completed within a millisecond window.

[0071] After the update is complete, the graph incremental update engine performs a consistency verification on the updated knowledge graph.

[0072] In this embodiment, consistency verification includes two dimensions: structural consistency and semantic consistency.

[0073] Specifically, structural consistency requires that the updated subgraph contains no isolated nodes, meaning each node is connected to at least one relation, and that there are no abnormal cycles in circular dependencies. A cycle detection function is defined. Returns a Boolean value. If a cycle exists, it further determines whether the cycle is a legal loop allowed by the business, such as retry logic or recursive calls. The determination of a legal loop is based on the loop tolerance label marked in the historical design model.

[0074] Semantic consistency requires that the updated node attributes match the actual metrics in the source code. For example, the cyclomatic complexity and number of parameters of a method must be consistent with the results obtained from parsing the AST. Let the eigenvectors of the subgraph before the update be... After the update, it is: The feature vector contains the out-degree, in-degree, node type distribution, and average attribute value of each node. The graph consistency score is defined as:

[0075] ;

[0076] in, Describing the L1 norm, To prevent division by zero for extremely small positive numbers, this score measures the proportion of deviation in the overall features of the map before and after the update. It is the map consistency score, ranging from 0 to 1. A value closer to 1 indicates a smaller deviation in the overall features of the map before and after the update, and a more reasonable update; a lower value indicates severe distortion of the map changes, falling below a threshold. This will trigger a rollback. In this solution, the threshold... Set it to 0.85.

[0077] If Consistency is below the threshold The engine triggers a rollback operation to restore the subgraph to the snapshot state before the update and generates an alarm log for manual intervention.

[0078] If Consistency is higher than the threshold If so, the update is submitted and the corresponding cache subgraph in Redis and the version evolution record in InfluxDB are updated synchronously.

[0079] In this embodiment, the purpose of consistency verification is to quantitatively evaluate the quality of incremental updates, avoiding errors in event parsing or propagation rule defects that could cause the graph to gradually deviate from the true state of the software. The setting is based on the lower quartiles of the score distribution after collecting 10,000 historical correct updates, ensuring that the vast majority of normal updates pass verification while abnormal updates are blocked.

[0080] After verification, the updated graph, carrying the latest version tag and timestamp, enters a ready state. At this time, the graph incremental update engine sends a ready signal to the test generation engine, which carries the set of effects involved in this update. And the change type label for each affected node.

[0081] In the above steps, step 2 is responsible for monitoring iterative operations such as code submission, requirement modification, and defect repair, encapsulating change information into standardized change event messages, and pushing them to the message queue; step 3 continuously subscribes to and listens to the message queue, using the change message output by step 2 as the only input for subsequent processing.

[0082] Step 4: Based on the updated knowledge graph, test and verify the functional changes and potential defects caused by this iteration, and generate a structured feedback data package.

[0083] Specifically, processing is carried out based on the latest knowledge graph that has completed incremental updates and passed consistency verification; key business paths and data flow links associated with changes are traversed, and test scenarios covering new business logic are constructed by integrating equivalence class partitioning and boundary value analysis testing methods. Standardized test cases containing test inputs, expected outputs, and execution steps are automatically generated and connected to the continuous integration process to accurately verify the functional changes and potential defect risks brought about by this iteration.

[0084] In a further implementation, such as Figure 4 and Figure 5 As shown, step 4 further includes the following sub-steps:

[0085] Step 4-1: Change the path to extract the ready signal from Step 3. This set contains all affected nodes in this iteration and a change type label for each node. The label values ​​are taken from the set {Add, Modify, Delete}. The test generation engine uses... Each node in the graph is used as the endpoint. All call chains and data flow paths that can reach that node are traced backwards in the graph, defining a set of paths:

[0086] ;

[0087] in, This serves as a business entry point, such as an API interface or the starting point for scheduled tasks. To change the node, path length This indicates the call depth from the entry point to the change point. Each path in the data represents a potentially affected business scenario, and the path length is limited during extraction. , Based on the average call depth of the target business software, this solution sets it to 10 to avoid path explosion while covering the vast majority of business links.

[0088] For each path It records the attribute set of all nodes on the path, including the method input parameter type, return value type, precondition label, and the read and write position of variables in the data stream. This information constitutes the data dictionary for generating test input later.

[0089] Step 4-2: Based on the data dictionary, for the path set For each path, three types of test coverage targets are constructed:

[0090] Path coverage requires test cases to execute all nodes of the complete execution path.

[0091] Branch coverage requires that the true / false branches of all decision nodes within the path be covered;

[0092] Data flow coverage requires that every instance of a variable defined must be traversed until all instances where it is subsequently used.

[0093] To quantify coverage adequacy, path coverage rate is defined as:

[0094] ;

[0095] in, This represents the path coverage rate, with a value ranging from 0 to 1. The closer the value is to 1, the more complete the path coverage. The set represents the number of valid business paths successfully covered by the test cases, with the absolute value sign indicating the total number of elements in the set; | |Refers to the total number of all business paths to be tested, filtered by the scope of the change's impact.

[0096] Furthermore, branch coverage is defined as:

[0097] ;

[0098] in, Branch coverage is the final calculated quantitative indicator of branch coverage. It is obtained by dividing the sum of the covered branches of all paths by the sum of all branches of all paths. For a single path Total number of all decision branches included. For a single path The number of decision branches successfully covered by the tested cases; This is the total number of covered branches in all paths to be tested. This is the total sum of all branches contained in the entire path to be tested.

[0099] Furthermore, the data flow coverage rate is defined as follows:

[0100] ;

[0101] in, For path Variable definition above - use the total number of pairs, Use the number of pairs for the already traversed definition.

[0102] The three coverage metrics are combined to form the test adequacy score:

[0103] .

[0104] In this embodiment, the weighting coefficient The weights are set to 0.4, 0.35, and 0.25 respectively. This weight allocation is derived by inversely calculating the proportion of escape defects caused by the three types of missing coverage in the historical defect data. The purpose is to guide the test generation engine to prioritize the coverage of high-risk paths.

[0105] For each path to be covered, the test generation engine, based on the input parameter types and preconditions of the nodes on the path, calls the equivalence class partitioning strategy to divide the legal value range of each input parameter into valid and invalid equivalence classes. At the same time, it combines the boundary value analysis strategy to extract the lower bound, upper bound, and nearby boundary points of the value range of each parameter, generating an initial candidate input value set. ,Will Substitute the value combination into the path The entry node performs symbolic simulation execution. During the simulation, the actual path of each conditional decision node is recorded and compared with the expected branch. If all conditional branches are consistent with the path definition, the set of input values ​​is retained as valid test input. If there is branch deviation, adjustments are made. The values ​​in the input are taken and re-simulated; this iterative process executes at most once. The wheel is used to ensure generation efficiency.

[0106] Step 4-3: Convert a single business path The corresponding set of valid input values ​​is converted into a standardized test case document.

[0107] Each use case document contains a unique identifier. ;

[0108] Preconditions describe the state required by the target business software before the execution of this use case, such as the login state of a specific user or the pre-configuration of specific data.

[0109] Test input sequence according to path The order in which the above methods are called is organized into a set of key-value pairs;

[0110] The expected output is defined as the path endpoint. The return value or exception type thrown, and the expected state of all assertion checkpoints on the path;

[0111] The execution steps are broken down from the entry node. To the change node For each method call and the specific values ​​of its input parameters, two copies are generated simultaneously during test case instantiation:

[0112] One version is a natural language description, for testers to review and understand the content;

[0113] One is an executable script skeleton, generated based on the project's accompanying test framework template.

[0114] The Java project generates JUnit test classes, the Python project generates pytest test functions, and assertion placeholders are reserved inside the script skeleton, to be filled with specific expected values ​​later.

[0115] Step 4-4: The assembled executable test cases are automatically integrated into the continuous integration pipeline. The test generation engine calls the Jenkins and GitLabCI interfaces to create iterative test tasks and automatically triggers test tasks when the code is merged into the main branch.

[0116] Based on the change type labels output in step 3, the execution priority of test cases is determined: test cases corresponding to deletion changes are set to high priority, test cases corresponding to modification changes are set to medium priority, and test cases corresponding to new changes are set to normal priority. The pipeline prioritizes scheduling high-priority test cases to expose iteration defects early.

[0117] After all test cases have been executed, a standardized test report is generated, recording the results of each test case, the deviation between the actual output and the expected output, and three types of coverage indicators: path / branch / data flow. The test report and the operation log are integrated into a feedback data package.

[0118] In each sub-step of step 4, standardized test cases are first generated internally and connected to the continuous integration pipeline to complete the test. After the test is completed, the test report and execution log are summarized and packaged into a feedback data packet, which is the final data carrier output from step 4 to step 5.

[0119] In this embodiment, the feedback data packet is a structured JSON standardized data packet, which is a key-value pair structured encapsulation with unified field naming, which facilitates parsing and extraction in step 5. It internally collects three core contents: basic test indicators, test case execution details, and system operation log fragments.

[0120] The feedback data packet is a single-iteration independent data packet, with a unique iteration number and change batch label to achieve data traceability. The specific structure of a single-iteration feedback data packet is shown in the following example:

[0121] {"iteration_id": "ITER_20260624_001", "change_type": "modify", "source_module": "order payment module", "coverage_data": { "path_coverage": 0.92, "branch_coverage": 0.89, "data_flow_coverage": 0.87}, "defect_info": { "detect_defect_count": 2, "critical_defect": 1, "defect_related_node": ["payment callback verification node", "balance deduction node"]}, "case_exec_result": "pass_partial", "execution_log_snippet": "pipeline execution time 12.6s, high-priority test cases were executed first"}.

[0122] Step 5: The feedback data packet encapsulated in Step 4 carries all test feedback data, such as test coverage and defect detection results. Step 5 receives this data packet and extracts its internal data to complete the adaptive optimization and adjustment of the knowledge graph.

[0123] For logical paths with insufficient test coverage or frequent defects, the system will automatically adjust the weight or association strength of the corresponding node in the knowledge graph, thereby achieving self-correction and continuous optimization of the knowledge graph.

[0124] This invention also provides an electronic device, including a memory and a processor, wherein the memory is coupled to the processor; wherein the memory is used to store program data, and the processor is used to execute the program data to implement the method described in any embodiment.

[0125] This invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in any of the embodiments.

[0126] The computer-readable storage medium can be an internal storage unit of any data processing device described in any of the foregoing embodiments, such as a hard disk or memory. The computer-readable storage medium can also be any data processing device, such as a plug-in hard disk, smart media card (SMC), SD card, flash card, etc., equipped on the device. Furthermore, the computer-readable storage medium can include both internal storage units of any data processing device and external storage devices. The computer-readable storage medium is used to store the computer program and other programs and data required by the data processing device, and can also be used to temporarily store data that has been output or will be output.

[0127] The above embodiments are only used to illustrate the design concept and features of the present invention, and their purpose is to enable those skilled in the art to understand the content of the present invention and implement it accordingly. The protection scope of the present invention is not limited to the above embodiments. Therefore, all equivalent changes or modifications made based on the principles and design ideas disclosed in the present invention are within the protection scope of the present invention.

Claims

1. A method for generating automated software tests throughout its entire lifecycle, characterized in that, include: Analyze multi-source data related to the software project to construct an initial knowledge graph. The initial knowledge graph is stored in a graph database, and a timestamp and version tag are attached to each node and relationship. Obtain the iteration events of the software project; Based on the iterative events, the initial knowledge graph is incrementally updated to obtain the updated knowledge graph; Based on the updated knowledge graph, test and verify the functional changes and potential defects caused by this iteration, and generate a feedback data package; Data is extracted from the feedback data packet, and the updated knowledge graph is adaptively optimized.

2. The method according to claim 1, characterized in that, Analyze multi-source data related to software projects and construct an initial knowledge graph. This includes: analyzing multi-source data containing requirements documents, design models, source code version history, and test case libraries, using a graph data model for unified representation, and constructing an initial knowledge graph with business entities, functional modules, data flows, and control dependencies as nodes.

3. The method according to claim 1, characterized in that, Acquiring iteration events of the software project includes: integrating listeners into the development environment of the software project to monitor code commits, requirement change requests, defect fix records, and deployment pipeline status; wherein, once any modification is captured by the version control system, the listener generates a structured event and publishes the event to a message queue.

4. The method according to claim 1, characterized in that, Based on the iterative events, the initial knowledge graph is incrementally updated, including: The impact analysis of the iterative events is performed based on the graph incremental update engine to identify the nodes and relationships in the initial knowledge graph that need to be modified. An incremental update algorithm is used to reconstruct only the affected subgraphs, while retaining the graph structure of the unchanged parts, to obtain the updated knowledge graph; The updated knowledge graph is then subjected to consistency verification.

5. The method according to claim 4, characterized in that, The consistency verification includes structural consistency verification and semantic consistency verification; The structural consistency verification is used to ensure that there are no isolated nodes in the updated subgraph; The semantic consistency verification is used to ensure that the updated node attributes match the actual metric values ​​in the source code. When the matching degree is lower than a preset threshold, the graph incremental update engine triggers a rollback operation to restore the subgraph to the snapshot state before the update and generates an alarm log for manual intervention.

6. The method according to claim 1, characterized in that, Based on the updated knowledge graph, test and verify the functional changes and potential defect risks caused by this iteration, including: traversing the key business paths and data flow links associated with the changes, integrating equivalence class partitioning and boundary value analysis testing methods to construct test scenarios covering the new business logic, automatically generating standardized test cases containing test inputs, expected outputs, and execution steps, and connecting to the continuous integration process.

7. The method according to claim 6, characterized in that, It iterates through the key business paths and data flow links associated with the changes, integrates equivalence class partitioning and boundary value analysis testing methods to construct test scenarios covering the newly added business logic, and automatically generates standardized test cases containing test inputs, expected outputs, and execution steps, including: Traverse the key business paths and data flow links associated with the change, trace the call chain and data flow path in reverse with the change node as the endpoint, extract the input parameter type, return value type, precondition label and read / write position of variables in the data flow of the nodes on the path, and generate a data dictionary; Based on the data dictionary, a coverage target including path coverage, branch coverage and data flow coverage is constructed for each path to be tested. The coverage rates of the three types of coverage targets are weighted and fused as a test sufficiency score to guide the test generation engine to prioritize the coverage of high-risk paths. For the path to be covered, the test generation engine generates candidate inputs, verifies whether the candidate inputs meet the expected path branches through symbolic simulation execution, and filters valid test inputs. Valid test inputs are instantiated into standardized test cases, where a natural language description version and an executable script skeleton for automated execution are generated for each test case; The standardized test cases are automatically integrated into the continuous integration pipeline, and test tasks are automatically triggered during code merging, with priority given to scheduling test cases corresponding to the deletion changes; After the test is completed, a standardized test report is generated, which records the test case execution results, the deviation between the actual output and the expected output, and various coverage indicators. The test report and the execution log are then encapsulated into a structured feedback data package.

8. The method according to claim 1, characterized in that, The updated knowledge graph is adaptively optimized, including: for logical paths where the test coverage is lower than the preset coverage rate or the frequency of defects is higher than the preset frequency, adjusting the weight or association strength of the corresponding node in the graph, so as to realize the self-correction and continuous optimization of the knowledge graph.

9. An electronic device comprising a memory and a processor, characterized in that, The memory is coupled to the processor; wherein the memory is used to store program data, and the processor is used to execute the program data to implement the method as described in any one of claims 1-8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-8.

Images