Intelligent evaluation method for code change impact range based on large model and twin simulation

Abstract

The application discloses a code change influence range intelligent evaluation method based on a large model and twin simulation, and specifically comprises the following steps: obtaining code differences and engineering context to form analysis input; analyzing a calling chain and a data dependency chain to construct a dependency graph, and generating virtual code nodes and function mapping; inputting the differences, the context and the virtual nodes into a CodeGen multi-branch structure to form a unified semantic representation; outputting a change description through a generated header, outputting a function influence probability and a risk score through a discrimination header; mapping to form an affected function list, a risk level sequence and a structured evaluation report; sending the report, determining a regression test range, a priority and a test plan adjustment result. The application has the advantages of accurate code influence identification and efficient test positioning.

Description

Technical Field

[0001] This invention relates to the field of code impact assessment technology, and in particular to an intelligent assessment method for the scope of impact of code changes based on large models and twin simulations. Background Technology

[0002] In software continuous integration and rapid iteration scenarios, code changes occur frequently. Developers typically need to manually analyze change files, differing lines, call relationships, and dependency files to determine whether the changes affect existing business functions. Assessing the impact of existing code often relies on static scanning, rule matching, or human experience, which can identify some direct call relationships but lacks sufficient support for cross-module calls, data transfer chains, indirect business impacts, and test scope derivation.

[0003] Especially in large-scale projects, the code structure is complex, and there are multiple layers of mapping between business functions and underlying code. Simply relying on file paths or function calls is insufficient to accurately determine the actual affected functions, easily leading to omissions in the scope of impact or overreach in the testing scope. While some tools introduce code analysis models to generate change notes, they typically focus on semantic code interpretation and lack linkage with business functions, simulation nodes, and regression test plans. Existing methods also struggle to combine with twin simulation environments to verify the impact on functions corresponding to virtual code nodes, resulting in a lack of unified criteria for risk scoring, test prioritization, and test plan adjustments.

[0004] Therefore, there is a need for an intelligent assessment method for the impact of code changes that can integrate code differences, engineering context, dependency graphs, large model semantic analysis, and twin simulation results. Summary of the Invention

[0005] One objective of this invention is to propose an intelligent assessment method for the impact scope of code changes based on large models and twin simulations. This invention introduces a dependency graph construction mechanism and a twin simulation impact judgment model to perform joint analysis on code differences, call chains, data dependency chains, and business function mappings, thereby constructing an intelligent assessment process for the impact scope of code changes. This method has the advantages of accurate impact identification, clear risk classification, and efficient regression testing for localization.

[0006] The intelligent assessment method for the impact range of code changes based on large models and twin simulation according to embodiments of the present invention includes the following steps: Obtain the code difference information and project code context of the current build, including the list of changed files, the content of the differing lines, and the dependent files, and integrate them to form the analysis input; The code involved in the change is analyzed by performing call chain and data dependency chain analysis, constructing a dependency graph, including the code associated on the dependency chain in the analysis scope, and generating virtual code nodes and function mappings in the twin simulation environment; The code difference information, engineering code context and virtual nodes generated by twin simulation are input into the multi-branch semantic embedding structure of the CodeGen model. Function signatures, comments and calling contexts are independently encoded, and a unified semantic representation is formed through feature fusion. The fused semantic representation is input into the controllable generation / discrimination head of the CodeGen model. The generation head outputs code change descriptions, and the discrimination head outputs the probability of each business function being affected and risk score, thereby determining the actual impact on the corresponding functions of the twin simulation nodes. Based on the output of the discrimination header, code-level changes are mapped to the business function level, forming a list of affected functions and a risk level sequence; Compile a list of functions and a risk level sequence, and generate a structured assessment report, including affected functions, risk scores, and impact descriptions; The evaluation report was sent to R&D and testing personnel, and the results of twin simulation were used to help determine the scope of regression testing, testing priorities, and whether the test plan should be adjusted.

[0007] Optionally, the integration to form the analysis input specifically includes: Establish a mapping relationship between the list of changed files and the corresponding difference lines, and record the added, modified, and deleted lines and context information for each changed file; The dependency file information of each changed file is associated with the relationship of related modules to form a dependency file set and module mapping table; The mapping relationship and the set of dependent files are combined in units of files to generate a unified analysis input data structure, where each file entry contains the file path, difference line identifier, difference content, set of dependent files and related module information; The unified analysis input data structure is validated and standardized.

[0008] Optionally, the analysis of the code execution call chain and data dependency chain involved in the change includes the following steps: Read the integrated analysis input data structure to obtain the file path, difference line identifier, difference content, dependent file set, and associated module information for each changed file; For each differing line in the change file, parse the function or method call relationship, establish a call chain node, and record the call order and call context; Analyze the usage and transmission paths of variables and data structures involved in the difference rows, construct data dependency chains, and identify the dependencies between input, output, and intermediate variables; The call chain nodes are associated with the data dependency chain to form a dependency graph, which contains node type, call relationship, data flow and module level information; The dependency graph is filtered to include the call nodes related to the change line and the associated code on the data dependency chain in the analysis scope.

[0009] Optionally, the step of inputting code difference information, engineering code context, and virtual nodes generated by twin simulation into the multi-branch semantic embedding structure of the CodeGen model specifically includes: The file path, difference line identifier, difference content, and associated module information of each changed file are mapped to the set of dependent files to form an input vector sequence, and the input is separated according to three dimensions: function signature, comment text, and call context. The function signature sequence is written into the function branch encoding layer, where the function name, parameter list, and return type are lexicalized and mapped into a vector sequence. Position encoding is also performed. The comment text sequence is written into the comment branch encoding layer, where word segmentation, stop word removal, and semantic embedding are performed to generate vectors. The call context sequence is written into the context branch encoding layer, where nodes are expanded according to the call chain order and module level, and node type, call relationship, and context text are mapped into vector representations. The three-branch vector sequence is encoded by Transformer through an independent encoder. The function branch uses a self-attention mechanism, the annotation branch uses multi-head attention, and the context branch generates node embeddings by combining graph attention with the call chain. The output vector sequence is aligned with the time step and node order and then input into the fusion layer. A unified semantic representation vector is generated by weighted summation and linear mapping, while retaining the branch identifier. After the output vector of the fusion layer is normalized, it is input into the generator head and the discriminator head. The generator head constructs the prediction sequence, and the discriminator head generates the probability of the function being affected and the risk score distribution. The unified semantic representation and branch identifier participate in the generation and discrimination calculation. The operation is completed synchronously in batch processing mode.

[0010] Optionally, the description of the changes to the controllable generation head output code of the fused semantic representation input to the CodeGen model specifically includes: The unified semantic representation vector is input into the header sequence decoding layer in time step order, and the input sequence is built according to the function signature vector, the call context vector and the comment text vector. The header sequence decoding layer performs mask attention calculation on the generated input sequence to form the semantic state vector of the current time step, and maps the semantic state vector of the current time step with the output sequence of the historical time step to generate the context association vector. The contextual vectors are mapped to the lexical prediction layer according to the file path and call chain order, and change description lexical sequences are generated for the new, modified and deleted operations corresponding to the content of the different lines. The sequence of change descriptive terms is reorganized into a code change description sequence according to the order of call chain nodes and module hierarchy. At the same time, the node type, call relationship and associated module information of the virtual node are written into the corresponding position of the code change description sequence. The code change description sequence is generated by determining the end marker. The generated result is then mapped to the list of changed files, the difference line markers, and the associated module information to form a structured code change description result.

[0011] Optionally, the discrimination head outputs the probability of each business function being affected and a risk score, and the actual impact determination of the corresponding function of the twin simulation node specifically includes: The unified semantic representation vector and branch identifier are input into the discriminant classification layer, and a node classification input sequence is generated according to the call chain node order and module hierarchy order. The node classification input sequence generates a functional probability vector corresponding to the business function through linear mapping, and performs normalization calculation on each component of the functional probability vector to form the probability distribution of the business function being affected; The probability distribution of business functions being affected is correlated with the call relationships, data flow relationships, and virtual node mapping relationships in the dependency graph to generate a function impact correlation matrix. The functional impact correlation matrix generates a risk score input sequence based on node type, call relationship, and data dependency. The risk score input sequence generates the risk score value of the corresponding business function through the risk score layer. The probability distribution of business functions being affected and the risk score values ​​are mapped to virtual nodes generated by twin simulation. For each virtual node, an impact identifier, a risk level identifier, and an associated module identifier are generated for the corresponding function. The actual impact assessment results are generated based on the impact identifier, risk level identifier, and associated module identifier, forming a set of impact results for business functions.

[0012] Optionally, the generation of the structured assessment report, including the affected functions, risk scores, and impact descriptions, specifically includes: Establish a functional record sequence by classifying the impact identifier, associated module identifier, and risk score value in the set of business function impact results, and associate the business function name, change file path, difference line identifier, call chain node, and data dependency node accordingly to generate a business function impact mapping table. Map the sequence of change description terms in the code change description results to the corresponding positions in the business function impact mapping table according to the business function number to form an impact description text sequence. Divide the risk score values ​​into numerical ranges, mark the range from 0 to 0.3 as the first risk range, the range greater than 0.3 and not exceeding 0.7 as the second risk range, and the range greater than 0.7 and not exceeding 1 as the third risk range. Write the corresponding range identifiers into the corresponding fields of the business function impact mapping table. The impact mapping table of business functions is sorted according to the business function number, associated module identifier, and interval identifier to generate a list of affected functions and a risk level sequence. The list of affected functions, the risk level sequence, the impact description text sequence, and the corresponding change file path are combined to form a structured assessment report. The structured assessment report includes business function fields, risk score fields, risk interval fields, impact description fields, and associated module fields.

[0013] Optionally, sending the evaluation report to R&D and testing personnel, and using the twin simulation results to help determine the scope of regression testing, testing priorities, and whether to adjust the test plan, specifically includes: The business function fields, risk score fields, risk range fields, impact description fields, and associated module fields in the structured assessment report are used to generate a report distribution sequence according to the business function number. The report distribution sequence is then associated with the corresponding module identifier for R&D personnel and the corresponding test module identifier for test personnel to generate a report sending mapping table. The list of affected functions in the report sending mapping table is associated with the running results of virtual nodes generated by twin simulation. The number of associated calling nodes, the number of data dependent nodes, and the abnormal node identifiers are counted for each business function to form a test impact statistical sequence. The business functions in the test impact statistical sequence are sorted according to the risk score value and the number of abnormal nodes to generate a regression test function sequence and a test priority sequence. Send the regression test function sequence, test priority sequence, and impact description text sequence to the corresponding R&D personnel and testers. Compare the test function number, test sequence number, and test time number in the test plan. Mark the test records with number differences as adjustment records and generate test plan adjustment results.

[0014] The beneficial effects of this invention are: 1. This invention forms a dependency graph by jointly analyzing the call chain and data dependency chain, which can locate the scope of the change code association and reduce the impact of omissions.

[0015] 2. This invention uses the CodeGen multi-branch semantic embedding structure to encode function signatures, comments, and calling contexts separately, thereby forming a more complete semantic representation of the code.

[0016] 3. This invention generates a header output code change description in a controllable manner, so that a structured correspondence is formed between the changed content, the difference line, and the related modules.

[0017] 4. This invention maps code-level changes to the business function level by outputting the probability of business function being affected and risk score through the discrimination header, which facilitates risk classification.

[0018] 5. This invention combines the results of twin simulation virtual node operation to generate regression test range and test priority, which can assist in test plan adjustment and improve test resource utilization efficiency. Attached Figure Description

[0019] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart of the intelligent assessment method for the impact range of code changes based on large models and twin simulation proposed in this invention. Figure 2 This is a schematic diagram of the dependency graph and twin simulation implementation process of the intelligent evaluation method for the impact range of code changes based on large models and twin simulation proposed in this invention. Figure 3 This is a schematic diagram illustrating the implementation process of CodeGen's multi-branch generation and discrimination method for intelligent evaluation of the impact range of code changes based on large models and twin simulations, as proposed in this invention. Detailed Implementation

[0020] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0021] refer to Figures 1-3 The intelligent assessment method for the impact of code changes based on large models and twin simulations includes the following steps: Obtain the code difference information and project code context of the current build, including the list of changed files, the content of the differing lines, and the dependent files, and integrate them to form the analysis input; The code involved in the change is analyzed by performing call chain and data dependency chain analysis, constructing a dependency graph, including the code associated on the dependency chain in the analysis scope, and generating virtual code nodes and function mappings in the twin simulation environment; The code difference information, engineering code context and virtual nodes generated by twin simulation are input into the multi-branch semantic embedding structure of the CodeGen model. Function signatures, comments and calling contexts are independently encoded, and a unified semantic representation is formed through feature fusion. The fused semantic representation is input into the controllable generation / discrimination head of the CodeGen model. The generation head outputs code change descriptions, and the discrimination head outputs the probability of each business function being affected and risk score, thereby determining the actual impact on the corresponding functions of the twin simulation nodes. Based on the output of the discrimination header, code-level changes are mapped to the business function level, forming a list of affected functions and a risk level sequence; Compile a list of functions and a risk level sequence, and generate a structured assessment report, including affected functions, risk scores, and impact descriptions; The evaluation report was sent to R&D and testing personnel, and the results of twin simulation were used to help determine the scope of regression testing, testing priorities, and whether the test plan should be adjusted.

[0022] In this embodiment, the integration of analytical input specifically includes: Establish a mapping relationship between the list of changed files and the corresponding difference lines, and record the added, modified, and deleted lines and context information for each changed file; The dependency file information of each changed file is associated with the relationship of related modules to form a dependency file set and module mapping table; The mapping relationship and the set of dependent files are combined in units of files to generate a unified analysis input data structure, where each file entry contains the file path, difference line identifier, difference content, set of dependent files and related module information; The unified analysis input data structure is validated and standardized.

[0023] Specifically, the verification and standardization of the unified analysis input data structure includes: The system reads the file paths, difference row identifiers, difference content, dependent file sets, and associated module information from the unified analysis input data structure, and verifies whether each field is empty. For file paths, it performs path format standardization, converting relative and absolute paths to the same storage format. For difference row identifiers, it performs line number range verification and deletes difference row records that cannot match the source file location. For difference content, it performs encoding format standardization and special character escaping to form standard difference text. For dependent file sets, it performs duplicate file deletion and path consistency processing. For associated module information, it performs module number matching and deletes invalid records that are not bound to module numbers. Finally, it sorts the verified file entries by file path and difference row identifier to generate a standardized analysis input data structure.

[0024] In this embodiment, the analysis of the code execution call chain and data dependency chain involved in the change includes the following steps: Read the integrated analysis input data structure to obtain the file path, difference line identifier, difference content, dependent file set, and associated module information for each changed file; For each differing line in the change file, parse the function or method call relationship, establish a call chain node, and record the call order and call context; Analyze the usage and transmission paths of variables and data structures involved in the difference rows, construct data dependency chains, and identify the dependencies between input, output, and intermediate variables; The call chain nodes are associated with the data dependency chain to form a dependency graph, which contains node type, call relationship, data flow and module level information; The dependency graph is filtered to include the call nodes related to the change line and the associated code on the data dependency chain in the analysis scope.

[0025] Specifically, this involves resolving the function or method call relationships for each differing line in the change file, establishing a call chain node, and recording the call order and call context. Read the changed file path and the difference line identifier to locate the function or method code block containing the difference line; parse the function name, method name, input parameter fields, return fields, and called object in the code block; take the function or method containing the difference line as the starting call chain node, read the function or method call statements appearing in the difference line code, and take the called function or method as the lower-level call chain node; record the connection relationship between the starting call chain node and the lower-level call chain nodes according to the order of code execution to form a call sequence number; extract the file path, line number, module, call statement, and context code fragment corresponding to each call chain node to generate a call context record; associate and store the call chain nodes, call sequence number, and call context record to form a set of difference line call chain nodes.

[0026] Specifically, constructing a data dependency chain to identify the dependencies between inputs, outputs, and intermediate variables includes: Read the code block of the function or method containing the difference line, and extract the input parameter variables, local variables, object fields, return variables and externally passed data involved in the difference line; Record the data source relationships between variables according to variable assignment statements, conditional judgment statements, calculation statements, and return statements; Externally input data and input parameter variables are marked as input nodes, local variables and updated values ​​of object fields generated during the calculation process are marked as intermediate variable nodes, and return variables, write database fields, interface output fields and message sending fields are marked as output nodes. Input nodes, intermediate variable nodes and output nodes are connected according to the order of data transmission to form a data dependency chain.

[0027] Specifically, associating call chain nodes with data dependency chains to form a dependency graph includes: Read the previously generated call chain node set and data dependency chain, and extract the input variables, return variables and intermediate calculation variables involved in each function or method; Connect each function or method node with its corresponding input variables, intermediate variables, and output variables to form a chain of relationships from input to output; record the order of calls and data transfers according to the code execution order. At the same time, the file path, line number, module, and context information of each node are recorded in the associated data; The resulting structure can display the functions, call relationships, and variable passing in each differing row, thus forming a complete dependency network.

[0028] Specifically, the dependency graph is filtered to include the call nodes related to the change line and the associated code on the data dependency chain in the analysis scope, including: Read the completed dependency graph and identify all function or method nodes directly related to the difference row; Track the input, intermediate, and output variables involved in these nodes to determine all relevant code locations along the variable passing path; retain the code that has a direct or indirect data relationship with the difference line, that is, not only retain the code related to variables directly used or modified by the difference line, but also the places where these variables are passed in the program, calculated or used by other functions; Mark the function or method calls, variable calculations, assignment statements and return statements on these paths, and record the module, file and line number information located on these paths to form a code set that can be used for analysis; Remove nodes and data transmission chains that are irrelevant to the difference rows.

[0029] In this embodiment, inputting code difference information, engineering code context, and virtual nodes generated by twin simulation into the multi-branch semantic embedding structure of the CodeGen model specifically includes: The file path, difference line identifier, difference content, and associated module information of each changed file are mapped to the set of dependent files to form an input vector sequence, and the input is separated according to three dimensions: function signature, comment text, and call context. The function signature sequence is written into the function branch encoding layer, where the function name, parameter list, and return type are lexicalized and mapped into a vector sequence. Position encoding is also performed. The comment text sequence is written into the comment branch encoding layer, where word segmentation, stop word removal, and semantic embedding are performed to generate vectors. The call context sequence is written into the context branch encoding layer, where nodes are expanded according to the call chain order and module level, and node type, call relationship, and context text are mapped into vector representations. The three-branch vector sequence is encoded by Transformer through an independent encoder. The function branch uses a self-attention mechanism, the annotation branch uses multi-head attention, and the context branch generates node embeddings by combining graph attention with the call chain. The output vector sequence is aligned with the time step and node order and then input into the fusion layer. A unified semantic representation vector is generated by weighted summation and linear mapping, while retaining the branch identifier. After the output vector of the fusion layer is normalized, it is input into the generator head and the discriminator head. The generator head constructs the prediction sequence, and the discriminator head generates the probability of the function being affected and the risk score distribution. The unified semantic representation and branch identifier participate in the generation and discrimination calculation. The operation is completed synchronously in batch processing mode.

[0030] Specifically, the function signature sequence is written into the function branch encoding layer, and lexical processing is performed on the function name, parameter list, and return type, including: Read the name, input parameters, and return value type of each function, and encode the function name by breaking it down into the smallest unit by letters or symbols. Each parameter in the parameter list is split into two parts: type and name, arranged in the order of their appearance in the function, and each element is converted into a vector representation, which can be generated by word embedding or one-hot encoding. Perform the same splitting and vector mapping on the return type; add positional encoding to the vector sequence to preserve the parameter order and structural relationship; record the file path, module information and start and end line numbers of the function corresponding to each vector; form a processable numerical vector sequence.

[0031] Specifically, the three-branch vector sequence undergoes Transformer encoding via an independent encoder, including: The function branch encoder performs self-attention computation on the function name, parameter vector, and return type vector; The annotation branch encoder performs multi-head attention computation on the sequence of annotated text vectors; The context branch encoder combines the call chain order and module hierarchy information to perform graph attention calculation on the call context vector sequence to generate node embeddings; the vector sequences output by each branch are aligned according to time step and node order; the aligned vector sequences are input into the fusion layer, and a unified semantic representation vector is generated through weighted summation and linear mapping; the branch identifier is preserved, the vector is normalized, and input is provided for the generation head and the discrimination head.

[0032] The normalized output vector of the fusion layer is then input into the generator head and the discriminator head. The generator head constructs the prediction sequence, specifically including: The normalized unified semantic representation vector is input into the head sequence decoding layer in the order of time steps; in the sequence decoding layer, mask attention is performed on each time step vector to generate the semantic state vector of the current time step. The semantic state vector of the current time step is combined with the output sequence of the historical time steps to form a context association vector; the context association vector is input into the word prediction layer to generate a change description word sequence for the new, modified and deleted operations corresponding to the difference rows; The generated lexical sequences are recombined according to the call chain node order and module hierarchy order to form a complete code change description sequence, retaining the node type, call relationship and associated module information corresponding to the virtual nodes in the sequence; Once the end-of-process identifier determination sequence is generated, the results are mapped to the list of changed files, the difference line identifiers, and the associated module information, and a structured code change description is output.

[0033] In this embodiment, the description of the changes to the controllable generation head output code of the fused semantic representation input to the CodeGen model specifically includes: The unified semantic representation vector is input into the header sequence decoding layer in time step order, and the input sequence is built according to the function signature vector, the call context vector and the comment text vector. The header sequence decoding layer performs mask attention calculation on the generated input sequence to form the semantic state vector of the current time step, and maps the semantic state vector of the current time step with the output sequence of the historical time step to generate the context association vector. The contextual vectors are mapped to the lexical prediction layer according to the file path and call chain order, and change description lexical sequences are generated for the new, modified and deleted operations corresponding to the content of the different lines. The sequence of change descriptive terms is reorganized into a code change description sequence according to the order of call chain nodes and module hierarchy. At the same time, the node type, call relationship and associated module information of the virtual node are written into the corresponding position of the code change description sequence. The code change description sequence is generated by determining the end marker. The generated result is then mapped to the list of changed files, the difference line markers, and the associated module information to form a structured code change description result.

[0034] In this embodiment, the discriminator outputs the probability of each service function being affected and a risk score. The actual impact determination for the corresponding function of the twin simulation node specifically includes: The unified semantic representation vector and branch identifier are input into the discriminant classification layer, and a node classification input sequence is generated according to the call chain node order and module hierarchy order. The node classification input sequence generates a functional probability vector corresponding to the business function through linear mapping, and performs normalization calculation on each component of the functional probability vector to form the probability distribution of the business function being affected; The probability distribution of business functions being affected is correlated with the call relationships, data flow relationships, and virtual node mapping relationships in the dependency graph to generate a function impact correlation matrix. The functional impact correlation matrix generates a risk score input sequence based on node type, call relationship, and data dependency. The risk score input sequence generates the risk score value of the corresponding business function through the risk score layer. The probability distribution of business functions being affected and the risk score values ​​are mapped to virtual nodes generated by twin simulation. For each virtual node, an impact identifier, a risk level identifier, and an associated module identifier are generated for the corresponding function. The actual impact assessment results are generated based on the impact identifier, risk level identifier, and associated module identifier, forming a set of impact results for business functions.

[0035] Specifically, the unified semantic representation vector and branch identifier are input into the discriminant classification layer, and the node classification input sequence is generated according to the order of the call chain nodes and the module hierarchy. The normalized unified semantic representation vector is combined with the branch identifiers according to the node correspondence to form the input vector of each node; the nodes are arranged according to the call chain order to maintain the execution order of function or method calls; and the nodes are arranged according to the hierarchical order of the module to which they belong in the project structure to make the node order consistent with the code structure. The sorted vector sequence is input into the classification layer for subsequent calculation of the probability value and risk score of each node.

[0036] Specifically, the functional impact correlation matrix is ​​generated by associating the probability distribution of business functions being affected with the call relationships, data flow relationships, and virtual node mapping relationships in the dependency graph. Read the probability value and risk score of each node, and extract the calling order, data transmission relationship and virtual node mapping information of the corresponding nodes in the dependency graph; According to the calling order and data transmission path, the probability value of the node is paired with its corresponding dependent node to form a two-dimensional matrix, where each row represents the source node and each column represents the target node. The matrix records the probability value and risk score from the source node to the target node, while retaining the module and file information to which the node belongs; it summarizes the association information between all nodes to generate a complete node association matrix, which is used to represent the probability distribution and risk level of the difference row and its related nodes on the dependency chain.

[0037] Specifically, the risk scoring input sequence generates risk score values ​​for corresponding business functions through the risk scoring layer, including: Arrange the probability value, calling relationship and data transmission information corresponding to each node in the dependency graph in the node order to form a risk scoring input sequence; The input sequence is written into the risk scoring calculation layer, and linear mapping and weighted summation operations are performed on each node to calculate the risk contribution of the node on the dependency chain. By combining the module and file information of the node, the risk value is normalized to generate a risk score value corresponding to each node; the risk score values ​​are mapped to the node to form a complete risk score output sequence for subsequent evaluation and mapping.

[0038] Specifically, the actual impact assessment results are generated based on the impact identifier, risk level identifier, and associated module identifier, forming a set of business function impact results, which includes: Read the impact identifier, risk score value, and module information of each node; filter out the nodes affected by the change based on the impact identifier, and record the corresponding risk score value; Associate the module information to which a node belongs with the nodes that affect it to form a module-level mapping; sort the nodes according to the call chain order and module order, and integrate the results of related nodes in the same module; The compiled node information, risk scores, and module associations are summarized to generate a complete result set. Each record includes a node identifier, risk value, associated module information, and node order.

[0039] In this implementation, a structured assessment report is generated, including the affected functions, risk scores, and impact descriptions, specifically including: Establish a functional record sequence by classifying the impact identifier, associated module identifier, and risk score value in the set of business function impact results, and associate the business function name, change file path, difference line identifier, call chain node, and data dependency node accordingly to generate a business function impact mapping table. Map the sequence of change description terms in the code change description results to the corresponding positions in the business function impact mapping table according to the business function number to form an impact description text sequence. Divide the risk score values ​​into numerical ranges, mark the range from 0 to 0.3 as the first risk range, the range greater than 0.3 and not exceeding 0.7 as the second risk range, and the range greater than 0.7 and not exceeding 1 as the third risk range. Write the corresponding range identifiers into the corresponding fields of the business function impact mapping table. The impact mapping table of business functions is sorted according to the business function number, associated module identifier, and interval identifier to generate a list of affected functions and a risk level sequence. The list of affected functions, the risk level sequence, the impact description text sequence, and the corresponding change file path are combined to form a structured assessment report. The structured assessment report includes business function fields, risk score fields, risk interval fields, impact description fields, and associated module fields.

[0040] In this implementation, the evaluation report is sent to R&D and testing personnel, and the results of the twin simulation are used to help determine the scope of regression testing, testing priorities, and whether the test plan needs to be adjusted. Specifically, this includes: The business function fields, risk score fields, risk range fields, impact description fields, and associated module fields in the structured assessment report are used to generate a report distribution sequence according to the business function number. The report distribution sequence is then associated with the corresponding module identifier for R&D personnel and the corresponding test module identifier for test personnel to generate a report sending mapping table. The list of affected functions in the report sending mapping table is associated with the running results of virtual nodes generated by twin simulation. The number of associated calling nodes, the number of data dependent nodes, and the abnormal node identifiers are counted for each business function to form a test impact statistical sequence. The business functions in the test impact statistical sequence are sorted according to the risk score value and the number of abnormal nodes to generate a regression test function sequence and a test priority sequence. Send the regression test function sequence, test priority sequence, and impact description text sequence to the corresponding R&D personnel and testers. Compare the test function number, test sequence number, and test time number in the test plan. Mark the test records with number differences as adjustment records and generate test plan adjustment results.

[0041] Specifically, associating the report distribution sequence with the corresponding module identifier for R&D personnel and the corresponding test module identifier for test personnel includes: Read the module identifier, business function number, and risk score information of each record in the structured assessment report; obtain the identifier list of modules that R&D personnel are responsible for and the identifier list of modules that test personnel are responsible for testing; The report records are matched with the modules that the R&D personnel are responsible for, according to the module identifier, to generate a sequence of report items received by the R&D personnel; at the same time, the report records are matched with the test modules that the test personnel are responsible for, to generate a sequence of report items received by the test personnel. The matching results are sorted and a report distribution sequence is generated in a unified manner according to the function number and module identifier to ensure that each record can be matched with specific R&D personnel and test personnel, forming a data table that can be sent directly for report distribution and subsequent regression test analysis.

[0042] Example 1: A software service platform uses a microservice architecture to handle business functions such as order processing, account verification, settlement and accounting, message notification, and access control. Each build generates several code differences, typically distributed across the controller layer, service layer, data access layer, and common utility layer. Traditional methods rely on developers reading commit logs, checking changed file paths, and manually tracing function call relationships, followed by testers using experience to narrow down the regression scope. Because there are multiple levels of calls and data transfer between business functions and the underlying code, an adjustment to an interface parameter can affect multiple business functions after passing through service methods, caching components, message queues, and database fields. Manual investigation is prone to overlooking indirect impacts and may also include unrelated functions in the test, resulting in an overly broad test scope.

[0043] In this scenario, a single platform build involves 26 change files, 184 lines of differing content, and 49 directly dependent files. The changes are concentrated in order status synchronization, discount rule calculation, account balance verification, and exception message write-back. Superficially, the main modifications are in the order service module, but in the code call chain, order status synchronization calls the settlement and accounting component, which in turn reads the account balance verification result, and exception message write-back also enters the notification service. If judged solely by file ownership, testers would typically prioritize testing the order service, easily overlooking the account and message notification stages. This embodiment, through dependency graphs, CodeGen multi-branch semantic embedding structures, and twin simulation node linkage, transforms code-level changes into business function-level impact results, solving the problems of long manual troubleshooting chains, inconsistent documentation, and difficulty in determining test priorities.

[0044] After the system is built, it reads the code difference information and first organizes the list of changed files, the content of the differing lines, the set of dependent files, and the information of related modules into a unified analysis input. Each file entry records the file path, the difference line identifier, the difference content, the set of dependent files, and the information of related modules to avoid losing context when only seeing a single file during subsequent analysis. Subsequently, the system parses the call relationships of the functions containing the differing lines, identifies the upstream entry point, the current calling method, and the downstream called method, and reads the variables, object fields, and return values ​​involved in the differing lines, tracing the data propagation path from input parameters to intermediate variables, output objects, cached fields, and message body fields. The call chain nodes and data dependency chains are merged to form a dependency graph, in which each node carries a node type, call relationship, data flow direction, and module level label.

[0045] After the dependency graph is generated, the system includes the related call nodes and associated code on the data dependency chain in the analysis scope, generating virtual code nodes in the twin simulation environment. These virtual code nodes are mapped to business functions such as order submission, order cancellation, discount calculation, account deduction, and notification push. For changes to the order status synchronization function, the system establishes order status nodes, settlement calculation nodes, account balance nodes, and message write-back nodes in the twin simulation environment, recording input parameters, output results, and abnormal states respectively. This processing allows testers to see that code changes not only remain at the order service layer but may also propagate to settlement, account, and notification functions.

[0046] During the semantic analysis phase, the system inputs code difference information, project code context, and virtual code nodes into the multi-branch semantic embedding structure of the CodeGen model. The function signature branch encodes the function name, parameter list, and return type; the comment text branch encodes comments, interface descriptions, and exception descriptions; and the call context branch expands nodes according to the call chain order and module hierarchy, generating node embeddings through graph attention. The outputs of the three branches are aligned in time step and node order, and then weighted and fused to form a unified semantic representation. This unified semantic representation is simultaneously input into a generation head and a discrimination head. The generation head outputs code change descriptions, and the discrimination head outputs the impact probability and risk score for each business function.

[0047] The output description in the generation header is no longer a simple submission summary, but rather a detailed mapping of add, modify, and delete operations to different rows, related modules, and virtual nodes. For example, changes to the order status field judgment conditions are reorganized into explanatory texts such as adjustments to order status synchronization logic, changes to settlement trigger conditions, and changes to the abnormal message write-back path. The discrimination header combines the call relationships, data flow relationships, and virtual node mapping relationships in the dependency graph to generate a business function impact correlation matrix and output a risk score. The system forms a risk level sequence based on risk scores falling into three ranges: 0 to 0.3, greater than 0.3 but not exceeding 0.7, and greater than 0.7 but not exceeding 1. Finally, the system compiles the affected functions, risk scores, risk ranges, impact descriptions, and related modules into a structured evaluation report, which is sent to the corresponding R&D and testing personnel. After reading the report, the testers adjust the testing order according to the regression testing function sequence and test priority sequence, prioritizing the verification of high-risk functions, then supplementing with medium-risk functions, and handling low-risk functions through sampling.

[0048] To verify the feasibility of this invention in practice, it was applied to the code build evaluation environment of a software service platform, and thirty consecutive batches of build records were selected for comparison. Each batch of builds included change files, differing lines, dependent files, related modules, test execution records, and defect backtracking records. The comparison method used manually evaluated records as a baseline, and then the structured evaluation report output by this invention was used to compare the number of identified impact functions, the number of omitted functions, the number of misjudged functions, report generation time, the number of regression test cases, defect discovery lead time, and the number of test plan adjustments. Statistical results show that this invention, without increasing the burden of manual reading, can extend code impact analysis from the file level to the business function level and incorporate abnormal operation of twin simulation nodes into test ranking.

[0049] In thirty build cycles, the manual method identified an average of 11 affected functions per cycle, while this invention identified an average of 14 affected functions. Three of these affected functions were indirectly affected due to cross-module data transfer. The manual method missed an average of 3.2 affected functions per cycle, while this invention missed an average of 0.8. The manual method took an average of 98 minutes to generate a report, while this invention took an average of 22 minutes. The number of regression test cases decreased from an average of 167 to 124, but this did not reduce the number of defects found. Conversely, the defect discovery order for high-risk functions shifted significantly earlier, with the first high-risk defect being discovered an average of 27 test cases earlier. Therefore, this invention enables R&D and testing personnel to understand the scope of code changes more quickly, reducing the reliance on experience to expand the testing scope.

[0050] Table 1: Comparison of Data from Code Change Impact Assessment Implementation

[0051] Table 1 reflects the differences between the two evaluation methods for the same batch of build records. The average number of change files for all thirty batches of builds was 26, the average number of difference lines was 184, and the average number of direct dependency files was 49, indicating that the input conditions faced by both methods were consistent. The manual evaluation method identified an average of 11 affected functions, while the method of this invention identified an average of 14. The three additional functions mainly came from data dependency chains and virtual code node mapping results, such as the transmission of order status field changes to account balance verification, message write-back, and settlement trigger positions. The number of missed affected functions decreased from 3.2 to 0.8, indicating that the omissions were significantly reduced after the dependency graph included indirect calls and field transmission in the analysis scope. The number of misjudged functions decreased from 5.6 to 2.1, indicating that this invention does not simply expand the scope but uses discriminant risk scoring and twin simulation results for screening. The report generation time was shortened from 98 minutes to 22 minutes, mainly because change files, difference lines, related modules, and impact descriptions can be automatically assembled into a structured evaluation report. The number of regression test cases decreased from 167 to 124, a reduction of 43, but the initial coverage rate of high-risk functions increased from 71.4% to 93.6%, indicating that the compressed test scope still prioritized coverage of critical functions. The location of the first high-risk defect was moved from test case number 64 to test case number 37, an improvement of 27 test cases, demonstrating the direct guiding role of the risk level sequence on the test order. The number of test plan adjustment records decreased from 18 to 9, and the average time for development confirmation shortened from 46 minutes to 19 minutes. This indicates that after the report field completeness rate improved from 82.5% to 97.8%, the understanding of the impact scope between development and testing became more consistent, resulting in less communication and rework.

[0052] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. An intelligent assessment method for the impact range of code changes based on large models and twin simulations, characterized in that, Includes the following steps: Obtain the code difference information and project code context of the current build, including the list of changed files, the content of the differing lines, and the dependent files, and integrate them to form the analysis input; The code involved in the change is analyzed by performing call chain and data dependency chain analysis, constructing a dependency graph, including the code associated on the dependency chain in the analysis scope, and generating virtual code nodes and function mappings in the twin simulation environment; The code difference information, engineering code context and virtual nodes generated by twin simulation are input into the multi-branch semantic embedding structure of the CodeGen model. Function signatures, comments and calling contexts are independently encoded, and a unified semantic representation is formed through feature fusion. The fused semantic representation is input into the controllable generation / discrimination head of the CodeGen model. The generation head outputs code change descriptions, and the discrimination head outputs the probability of each business function being affected and risk score, thereby determining the actual impact on the corresponding functions of the twin simulation nodes. Based on the output of the discrimination header, code-level changes are mapped to the business function level, forming a list of affected functions and a risk level sequence; Compile a list of functions and a risk level sequence, and generate a structured assessment report, including affected functions, risk scores, and impact descriptions; The evaluation report was sent to R&D and testing personnel, and the results of twin simulation were used to help determine the scope of regression testing, testing priorities, and whether the test plan should be adjusted.

2. The intelligent assessment method for the impact range of code changes based on large models and twin simulations according to claim 1, characterized in that, The integrated analysis input specifically includes: Establish a mapping relationship between the list of changed files and the corresponding difference lines, and record the added, modified, and deleted lines and context information for each changed file; The dependency file information of each changed file is associated with the relationship of related modules to form a dependency file set and module mapping table; The mapping relationship and the set of dependent files are combined in units of files to generate a unified analysis input data structure, where each file entry contains the file path, difference line identifier, difference content, set of dependent files and related module information; The unified analysis input data structure is validated and standardized.

3. The intelligent assessment method for the impact range of code changes based on large models and twin simulations according to claim 1, characterized in that, The analysis of the code execution call chain and data dependency chain involved in the change includes the following steps: Read the integrated analysis input data structure to obtain the file path, difference line identifier, difference content, dependent file set, and associated module information for each changed file; For each differing line in the change file, parse the function or method call relationship, establish a call chain node, and record the call order and call context; Analyze the usage and transmission paths of variables and data structures involved in the difference rows, construct data dependency chains, and identify the dependencies between input, output, and intermediate variables; The call chain nodes are associated with the data dependency chain to form a dependency graph, which contains node type, call relationship, data flow and module level information; The dependency graph is filtered to include the call nodes related to the change line and the associated code on the data dependency chain in the analysis scope.

4. The intelligent assessment method for the impact range of code changes based on large models and twin simulations according to claim 1, characterized in that, The multi-branch semantic embedding structure of the CodeGen model, which inputs code difference information, engineering code context, and virtual nodes generated by twin simulation, specifically includes: The file path, difference line identifier, difference content, and associated module information of each changed file are mapped to the set of dependent files to form an input vector sequence, and the input is separated according to three dimensions: function signature, comment text, and call context. The function signature sequence is written into the function branch encoding layer, where the function name, parameter list, and return type are lexicalized and mapped into a vector sequence. Position encoding is also performed. The comment text sequence is written into the comment branch encoding layer, where word segmentation, stop word removal, and semantic embedding are performed to generate vectors. The call context sequence is written into the context branch encoding layer, where nodes are expanded according to the call chain order and module level, and node type, call relationship, and context text are mapped into vector representations. The three-branch vector sequence is encoded by Transformer through an independent encoder. The function branch uses a self-attention mechanism, the annotation branch uses multi-head attention, and the context branch generates node embeddings by combining graph attention with the call chain. The output vector sequence is aligned with the time step and node order and then input into the fusion layer. A unified semantic representation vector is generated by weighted summation and linear mapping, while retaining the branch identifier. After the output vector of the fusion layer is normalized, it is input into the generator head and the discriminator head. The generator head constructs the prediction sequence, and the discriminator head generates the probability of the function being affected and the risk score distribution. The unified semantic representation and branch identifier participate in the generation and discrimination calculation. The operation is completed synchronously in batch processing mode.

5. The intelligent assessment method for the impact range of code changes based on large models and twin simulations according to claim 1, characterized in that, The description of the changes to the controllable generator head output code of the CodeGen model, which inputs the fused semantic representation, specifically includes: The unified semantic representation vector is input into the header sequence decoding layer in time step order, and the input sequence is built according to the function signature vector, the call context vector and the comment text vector. The header sequence decoding layer performs mask attention calculation on the generated input sequence to form the semantic state vector of the current time step, and maps the semantic state vector of the current time step with the output sequence of the historical time step to generate the context association vector. The contextual vectors are mapped to the lexical prediction layer according to the file path and call chain order, and change description lexical sequences are generated for the new, modified and deleted operations corresponding to the content of the different lines. The sequence of change descriptive terms is reorganized into a code change description sequence according to the order of call chain nodes and module hierarchy. At the same time, the node type, call relationship and associated module information of the virtual node are written into the corresponding position of the code change description sequence. The code change description sequence is generated by determining the end marker. The generated result is then mapped to the list of changed files, the difference line markers, and the associated module information to form a structured code change description result.

6. The intelligent assessment method for the impact range of code changes based on large models and twin simulations according to claim 1, characterized in that, The discrimination head outputs the probability of each business function being affected and a risk score, and the actual impact determination of the corresponding function of the twin simulation node specifically includes: The unified semantic representation vector and branch identifier are input into the discriminant classification layer, and a node classification input sequence is generated according to the call chain node order and module hierarchy order. The node classification input sequence generates a functional probability vector corresponding to the business function through linear mapping, and performs normalization calculation on each component of the functional probability vector to form the probability distribution of the business function being affected; The probability distribution of business functions being affected is correlated with the call relationships, data flow relationships, and virtual node mapping relationships in the dependency graph to generate a function impact correlation matrix. The functional impact correlation matrix generates a risk score input sequence based on node type, call relationship, and data dependency. The risk score input sequence generates the risk score value of the corresponding business function through the risk score layer. The probability distribution of business functions being affected and the risk score values ​​are mapped to virtual nodes generated by twin simulation. For each virtual node, an impact identifier, a risk level identifier, and an associated module identifier are generated for the corresponding function. The actual impact assessment results are generated based on the impact identifier, risk level identifier, and associated module identifier, forming a set of impact results for business functions.

7. The intelligent assessment method for the impact range of code changes based on large models and twin simulations according to claim 1, characterized in that, The generated structured assessment report, including the affected functions, risk scores, and impact descriptions, specifically includes: Establish a functional record sequence by classifying the impact identifier, associated module identifier, and risk score value in the set of business function impact results, and associate the business function name, change file path, difference line identifier, call chain node, and data dependency node accordingly to generate a business function impact mapping table. Map the sequence of change description terms in the code change description results to the corresponding positions in the business function impact mapping table according to the business function number to form an impact description text sequence. Divide the risk score values ​​into numerical ranges, mark the range from 0 to 0.3 as the first risk range, the range greater than 0.3 and not exceeding 0.7 as the second risk range, and the range greater than 0.7 and not exceeding 1 as the third risk range. Write the corresponding range identifiers into the corresponding fields of the business function impact mapping table. The impact mapping table of business functions is sorted according to the business function number, associated module identifier, and interval identifier to generate a list of affected functions and a risk level sequence. The list of affected functions, the risk level sequence, the impact description text sequence, and the corresponding change file path are combined to form a structured assessment report. The structured assessment report includes business function fields, risk score fields, risk interval fields, impact description fields, and associated module fields.

8. The intelligent assessment method for the impact range of code changes based on large models and twin simulations according to claim 1, characterized in that, The process of sending the evaluation report to R&D and testing personnel, and using the twin simulation results to help determine the scope of regression testing, testing priorities, and whether to adjust the test plan, specifically includes: The business function fields, risk score fields, risk range fields, impact description fields, and associated module fields in the structured assessment report are used to generate a report distribution sequence according to the business function number. The report distribution sequence is then associated with the corresponding module identifier for R&D personnel and the corresponding test module identifier for test personnel to generate a report sending mapping table. The list of affected functions in the report sending mapping table is associated with the running results of virtual nodes generated by twin simulation. The number of associated calling nodes, the number of data dependent nodes, and the abnormal node identifiers are counted for each business function to form a test impact statistical sequence. The business functions in the test impact statistical sequence are sorted according to the risk score value and the number of abnormal nodes to generate a regression test function sequence and a test priority sequence. Send the regression test function sequence, test priority sequence, and impact description text sequence to the corresponding R&D personnel and testers. Compare the test function number, test sequence number, and test time number in the test plan. Mark the test records with number differences as adjustment records and generate test plan adjustment results.

Images