Software integration evaluation method based on machine learning and static analysis

Abstract

The invention relates to the technical field of software engineering and software quality evaluation, and discloses a software integration evaluation method based on machine learning and static analysis, and the method comprises the following steps: S1, carrying out static analysis on software source codes, and generating a candidate defect list; s2, executing dynamic verification based on the candidate defect list, and collecting runtime data; s3, performing feature fusion on the static analysis result and the dynamic verification data to form a defect evaluation feature vector; s4, inputting the defect evaluation feature vector into a machine learning model, and evaluating the authenticity and severity of the defect; and S5, outputting a defect detection report. According to the method, by combining static analysis and dynamic verification, the defect and the influence range of the defect can be further confirmed, the false alarm rate in static analysis is effectively reduced, meanwhile, the defect of insufficient coverage of a dynamic verification path is overcome, and the comprehensiveness and accuracy of defect detection are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of software engineering and software quality evaluation, and in particular to a software integration evaluation method based on machine learning and static analysis. Background Art

[0002] As the scale and complexity of software systems continue to increase, software quality issues have gradually become an important factor restricting software development efficiency and system stability. In order to ensure the correctness and reliability of software, software integration detection technology is widely used in the software development life cycle.

[0003] At present, static analysis is the most commonly used defect detection method, which quickly identifies potential defects by scanning source code, such as null pointers, array out-of-bounds problems, etc. However, because static analysis relies on code rule matching and static logic deduction, its defect detection results have the following shortcomings: High false positive rate: Static analysis tools are often unable to accurately determine the actual triggerability of defects, resulting in a large number of false positives, which brings additional analysis burden to developers. Lack of runtime verification: Static analysis only performs reasoning based on code structure, cannot capture the dynamic behavior of the program at runtime, and is difficult to determine the impact of defects in actual execution. Limited coverage: In scenarios with complex path conditions and multi-module call relationships, static analysis is difficult to fully cover all potential defect paths, and there is a problem of missed reports.

[0004] At the same time, in recent years, machine learning technology has brought new solutions to defect detection. Through training on historical defect data, machine learning models can determine the authenticity of defects and quantify their severity, providing intelligent evaluation results. However, the detection effect of machine learning alone depends on high-quality data input, and feature extraction and fusion are still challenging. Summary of the invention

[0005] In order to make up for the above shortcomings, the present invention provides a software integration evaluation method based on machine learning and static analysis, aiming to improve the problems in the prior art such as high false alarm rate of static analysis, insufficient dynamic verification coverage, difficulty in determining the authenticity of defects and inability to quantify their severity.

[0006] In a first aspect, the present invention provides the following technical solution: a software integration evaluation method based on machine learning and static analysis, comprising the following steps:

[0007] S1: Perform static analysis on the software source code to generate a list of candidate defects;

[0008] S2: Based on the candidate defect list, perform dynamic verification and collect runtime data;

[0009] S3: Fusing the static analysis results with the dynamic verification data to form a defect assessment feature vector;

[0010] S4: Inputting the defect assessment feature vector into a machine learning model to assess the authenticity and severity of the defect;

[0011] S5: Output defect detection report.

[0012] Preferably, the step S1 further includes:

[0013] S1.1: configuring a rule base of a static analysis tool, wherein the rule base includes security rules, performance rules, and module dependency rules;

[0014] S1.2: Scan the software source code using static analysis tools to obtain preliminary defect detection results;

[0015] S1.3: De-duplicate the preliminary defect detection results, remove duplicate defects in the same code position, and retain a unique defect record;

[0016] S1.4: Extracting static features of defects based on a code static feature extraction algorithm, wherein the static features include code complexity, inter-module calling relationships, and defect descriptions;

[0017] S1.5: Clustering and filtering the extracted static features, clustering the defects based on feature similarity to form a final candidate defect list, wherein the feature similarity is calculated using the cosine similarity formula, specifically:

[0018]

[0019] Where A and B are the feature vectors of the defect, and n is the dimension of the feature.

[0020] Preferably, the code complexity in S1.4 is calculated by the cyclomatic complexity formula, specifically:

[0021] C=E-N+2P

[0022] Where C is the cyclomatic complexity, E is the number of edges in the program, N is the number of nodes in the program, and P is the number of connected subgraphs in the program.

[0023] Preferably, the step S2 further includes:

[0024] S2.1: Automatically generate test cases for the candidate defect list, wherein the test cases include unit tests and integration tests. Unit tests are generated by automated testing tools, and integration tests are implemented by manual supplementary design.

[0025] S2.2: Execute the generated test cases and use Valgrind to dynamically verify the defect path;

[0026] S2.3: Collecting runtime data during the dynamic verification process, wherein the runtime data includes execution exception data, path coverage data, and performance indicator data;

[0027] S2.4: performing feature extraction on the collected runtime data;

[0028] S2.5: Associate the extracted runtime features with the candidate defect paths to generate a defect verification dataset containing dynamic verification results for subsequent feature fusion and defect assessment.

[0029] Preferably, the step S3 further includes:

[0030] S3.1: Perform feature preprocessing on the static analysis results, wherein the features include code complexity, module dependency, defect type, and rule identification;

[0031] S3.2: Perform feature preprocessing on the dynamic verification data, wherein the dynamic features include execution anomaly features, path coverage features, and performance index features;

[0032] S3.3: performing data standardization processing on the static features and the dynamic features;

[0033] S3.4: perform feature fusion on the standardized static features and dynamic features;

[0034] S3.5: Filter the features with high contribution in the fused feature vector for input into the subsequent defect assessment model.

[0035] Preferably, the step S4 further comprises:

[0036] S4.1: Perform data segmentation on the defect assessment feature vector, and divide the data set into a training set, a validation set, and a test set, wherein the training set is used for model training, the validation set is used for hyperparameter adjustment, and the test set is used for model performance evaluation;

[0037] S4.2: Select a machine learning model as a defect assessment model, wherein the model is an XGBoost model based on a gradient boosting decision tree;

[0038] S4.3: Performing model training on the defect assessment feature vector;

[0039] S4.4: adjusting the hyperparameters of the XGBoost model through the validation set, wherein the hyperparameters include learning rate, maximum depth of the tree, and subsample ratio;

[0040] S4.5: Input the test set into the trained XGBoost model and output the defect authenticity and severity prediction results, where:

[0041] The authenticity of the defect is determined by the classification probability, and when the classification probability is greater than a threshold value θ, it is determined to be a real defect;

[0042] The severity of the defect is quantified by a prediction score, and the output range is between 0 and 1. The higher the prediction score, the more severe the defect.

[0043] Preferably, the execution exception data in S2.3 includes the exception type and the number of occurrences of the exception;

[0044] The path coverage data is calculated by the following formula:

[0045]

[0046] The CoveredLines is the number of code lines covered by the test execution, and the TotalLines is the total number of code lines on the defect path.

[0047] In a second aspect, the present invention provides the following technical solution: a software integration evaluation system based on machine learning and static analysis, the system comprising:

[0048] Static analysis module, used to perform static scanning on software source code, detect potential defects and extract static features;

[0049] Dynamic verification module, used to perform dynamic verification based on candidate defect paths of static analysis, collect runtime data and extract dynamic features;

[0050] The feature fusion module is used to fuse the static analysis results with the dynamic verification data to form a defect assessment feature vector;

[0051] The machine learning assessment module is used to assess the authenticity and severity of defects using machine learning models based on defect assessment feature vectors;

[0052] The report generation module is used to automatically generate software defect detection reports.

[0053] In the third aspect, the invention provides the following technical solution: a computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned software integration evaluation method based on machine learning and static analysis when executing the computer program.

[0054] In a fourth aspect, the present invention provides the following technical solution: a readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-mentioned software integration evaluation method based on machine learning and static analysis.

[0055] The present invention has the following beneficial effects:

[0056] 1. In the present invention, by combining static analysis and dynamic verification, potential defects can be quickly scanned without code execution, and whether these defects actually exist can be dynamically verified simultaneously. Candidate defect paths are generated through static analysis, and the defects and their impact range are further confirmed through dynamic verification, which effectively reduces the false alarm rate in static analysis, and at the same time makes up for the defect of insufficient coverage of dynamic verification paths, thereby improving the comprehensiveness and accuracy of defect detection.

[0057] 2. In the present invention, by adopting a machine learning model, the defect assessment feature vector is trained and evaluated to realize the authenticity determination and severity quantification of the defect. By learning from the historical defect data, the model can accurately judge the authenticity of the defect and output the classification probability; at the same time, it can quantify the severity of the defect and provide intuitive scoring results. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] Figure 1 This is a general method flow chart of a software integration evaluation method based on machine learning and static analysis proposed by the present invention;

[0059] Figure 2 A detailed flow chart of step S1 of a software integration evaluation method based on machine learning and static analysis proposed by the present invention;

[0060] Figure 3 A detailed flow chart of step S2 of a software integration evaluation method based on machine learning and static analysis proposed by the present invention;

[0061] Figure 4 A detailed flow chart of step S3 of a software integration evaluation method based on machine learning and static analysis proposed by the present invention;

[0062] Figure 5 A detailed flow chart of step S4 of a software integration evaluation method based on machine learning and static analysis proposed by the present invention;

[0063] Figure 6 This is a system architecture diagram of a software integration evaluation system based on machine learning and static analysis proposed in the present invention. DETAILED DESCRIPTION

[0064] The technical solutions in the embodiments of the present invention will be described clearly and completely below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0065] Embodiment 1

[0066] Reference Figure 1 In a first embodiment of the present invention, the present invention provides a software integration evaluation method based on machine learning and static analysis, comprising the following steps:

[0067] Reference Figure 2 ,S1: Perform static analysis on the software source code and generate a candidate defect list; including:

[0068] S1.1: Configure the rule base of the static analysis tool, which includes security rules, performance rules, and module dependency rules;

[0069] S1.2: Scan the software source code using static analysis tools to obtain preliminary defect detection results;

[0070] S1.3: Perform deduplication processing on the preliminary defect detection results, remove duplicate defects in the same code position, and retain unique defect records;

[0071] S1.4: Extract the static features of defects based on the code static feature extraction algorithm. The static features include code complexity, inter-module call relationship and defect description. The code complexity is calculated by the cyclomatic complexity formula, which is:

[0072] C=E-N+2P

[0073] Where C is the cyclomatic complexity, E is the number of edges in the program, N is the number of nodes in the program, and P is the number of connected subgraphs in the program.

[0074] S1.5: Cluster and filter the extracted static features, cluster the defects based on feature similarity to form a final candidate defect list, where the feature similarity is calculated using the cosine similarity formula, specifically:

[0075]

[0076] Where A and B are the feature vectors of the defect, and n is the dimension of the feature.

[0077] Specifically, static analysis is the basic link of the present invention. It can quickly locate potential defects through structured analysis of software code, combined with the rules of security, performance and module dependency, and provide the necessary data basis for subsequent dynamic verification and machine learning evaluation. Specifically, the static analysis process includes five links: rule configuration, code scanning, result deduplication, feature extraction and cluster filtering.

[0078] In this embodiment, the rule base of the static analysis tool is first configured to ensure that the static analysis tool can perform comprehensive detection for different types of software defects. Specifically, the rule base includes the following three types of rules:

[0079] Security rules: used to detect potential security-related defects, such as null pointer access, array out-of-bounds, unvalidated user input, SQL injection, etc.

[0080] Performance rules: detect software performance issues, including dead loops, unreleased resources, redundant code, memory leaks, etc.

[0081] Module dependency rules: Analyze the dependencies between code modules to locate defects such as cross-module call errors, circular dependencies, and excessive coupling between modules.

[0082] As an option, the rule base can be expanded or tailored according to specific project requirements. For example, for software projects with high security requirements, security rules can add static code injection defense, key leakage detection and other rules; for high-performance computing applications, resource consumption-related rules are given priority.

[0083] After the rule base is configured, the software source code is scanned by a static analysis tool. In this embodiment, a variety of mainstream static analysis tools can be used, such as SonarQube, CodeQL, and ClangStaticAnalyzer. These tools can perform in-depth analysis based on the syntax tree, control flow graph (CFG), and data flow graph (DFG) of the code. The specific process includes:

[0084] First, the tool performs syntax analysis on the code to identify syntax errors and basic structures in the code. Then, the tool performs rule matching based on the preset rule base to check the security, performance, and module dependency issues that may exist in the code one by one. Finally, the tool further performs cross-module analysis, builds a call relationship graph between code modules, and checks cross-module defects, such as unreasonable call paths or circular dependency issues.

[0085] It should be noted that the choice of static analysis tools can be adjusted according to the code language and project scale. For example, for C / C++ projects, ClangStaticAnalyzer has good analysis capabilities; for Java projects, SonarQube and CodeQL can effectively implement modular defect detection.

[0086] After obtaining the preliminary defect detection results, in this embodiment, the preliminary defect results are deduplicated to remove redundant information and ensure the accuracy and uniqueness of the candidate defect list. Specifically, the deduplication process includes the following aspects:

[0087] Deduplication of defect locations: For duplicate defect records that appear in the same code location (including file path and line number), one defect record is retained and other redundant items are removed;

[0088] Rule merging: For defects in the same code location detected by different rule identifiers, rule information is merged to ensure concise and clear results;

[0089] Redundancy filtering: Analyze the context of defects and eliminate defect records that do not affect functions or have the possibility of false alarms.

[0090] In this embodiment, based on the code static feature extraction algorithm, static features are further extracted from the processed candidate defects, and the static features include code complexity, inter-module calling relationship and defect description.

[0091] Specifically, code complexity is used to measure the complexity of code logic. In this embodiment, code complexity is calculated by cyclomatic complexity, which reflects the complexity of program control flow and is usually positively correlated with the probability of defect occurrence.

[0092] The calculation method of cyclomatic complexity includes: first, extracting the nodes and edges of the program based on the control flow graph of the code; then, calculating the value of cyclomatic complexity in combination with the number of connected subgraphs of the program.

[0093] For example, in a simple if-else control structure, the cyclomatic complexity is 2; for complex nested loop structures, the cyclomatic complexity increases significantly.

[0094] In a possible implementation, the inter-module call relationship generates a control flow graph (CFG) and a data flow graph (DFG) through a static analysis tool, and extracts the module call path information. For example, for a cross-module call path where function A calls function B, and then calls function C, its call chain can be recorded as A→B→C.

[0095] In addition, the defect description is extracted based on the rule identifier and tool output information to describe the defect type, location, and detection rules. For example, the description of a null pointer exception defect is "the variable is not checked for null value, which may cause null pointer access", and the description of a performance defect is "there is a code path where resources are not released, which may cause memory leaks."

[0096] After the feature extraction is completed, in this embodiment, the extracted static features are clustered and filtered to further optimize the candidate defect list and reduce redundant items.

[0097] Specifically: First, construct the feature expression of defects through static feature vectors, including code complexity value, call relationship chain and defect type label; second, calculate the feature similarity between defects and use the cosine similarity algorithm for measurement. For example, if two defects have similar code complexity, similar call relationship and the same type, they are considered to belong to the same defect category; then, cluster according to the similarity threshold, classify defects with similar features into one category, retain representative defects and eliminate redundant items; finally, filter the clustering results to eliminate defect records that are not representative or have a high probability of false alarms.

[0098] It should be noted that the threshold of feature clustering can be dynamically adjusted according to project characteristics to ensure the accuracy and effectiveness of the clustering effect.

[0099] Reference Figure 3 ,S2: Based on the candidate defect list, perform dynamic verification and collect runtime data;,S2.1: Automatically generate test cases for the candidate defect list. The test cases include unit tests and integration tests. Unit tests are generated by automated testing tools, and integration tests are implemented through manual supplementary design;

[0100] S2.2: Execute the generated test cases and use Valgrind to dynamically verify the defective paths;

[0101] S2.3: Runtime data is collected during the dynamic verification process. The runtime data includes execution exception data, path coverage data, and performance indicator data. The execution exception data includes exception type and number of exception occurrences.

[0102] The path coverage data is calculated using the following formula:

[0103]

[0104] Among them, CoveredLines is the number of code lines covered by the test execution, and TotalLines is the total number of code lines on the defect path.

[0105] S2.4: extract features from the collected runtime data;

[0106] S2.5: Associate the extracted runtime features with the candidate defect paths to generate a defect verification dataset containing dynamic verification results for subsequent feature fusion and defect assessment.

[0107] Specifically, this step combines automated testing with dynamic verification tools to perform execution verification on candidate defect paths, collect data features related to runtime status, and generate dynamic verification results, providing necessary data support for subsequent feature fusion and defect assessment.

[0108] In this embodiment, test cases are automatically generated for the candidate defect list, and the test cases include unit tests and integration tests. Specifically, the automated test case generation is implemented by an automated testing tool, which can automatically build input data and execution logic based on the code path of the candidate defect. For example, EvoSuite is used to automatically generate unit test code for a single function or code unit to cover possible branch conditions in the defect path.

[0109] As an option, for defect paths that cross modules or have complex dependencies, we use manual supplementation to design integrated test cases. Specifically, we manually build test scenarios and data inputs based on the module dependency information and call chains of candidate defects to ensure that the defect propagation path is covered in an integrated environment.

[0110] It should be noted that the combination of automatically generated test cases and manually supplemented integrated test cases can effectively improve the code coverage and defect location capabilities of dynamic verification.

[0111] In this embodiment, the generated test cases are executed, and Valgrind is used to dynamically verify the defective paths.

[0112] Specifically, Valgrind, as a dynamic instrumentation tool, inserts monitoring logic during code execution to capture the memory access status and abnormal behavior of the program during runtime. Before dynamic verification begins, the generated test cases are compiled with the target source code to form an executable file; during test execution, the Valgrind tool is used to load the executable file and verify the candidate defect paths one by one; Valgrind monitors the runtime status during execution, including memory allocation, access boundaries, unreleased resources, etc., and provides detailed dynamic verification results.

[0113] For example, in a scenario where the candidate defect path involves array out-of-bounds or pointer access, Valgrind can capture illegal memory access exceptions and record the specific location and number of occurrences.

[0114] In this embodiment, runtime data is collected during the dynamic verification process, and the runtime data includes execution exception data, path coverage data, and performance indicator data.

[0115] Specifically, the collection of runtime data includes the following three aspects:

[0116] Execution exception data: monitor the exception types during program execution, such as null pointer exceptions, memory leaks, array out-of-bounds, etc.; record the number of exceptions that occur to assist in analyzing the severity and impact of defects. Path coverage data: during program execution, calculate the path coverage by counting the number of lines of code executed and the total number of lines of code on the defect path:

[0117]

[0118] Among them, CoveredLines represents the number of code lines covered by the test execution, and TotalLines represents the total number of code lines on the defect path.

[0119] For example, in a certain test case, if the total number of code lines of the defective path is 100 lines, and the number of lines covered during the execution process is 85 lines, the path coverage is 85%.

[0120] Performance indicator data: monitors the performance consumption during program operation, including memory allocation, CPU execution time, etc. Memory consumption records the size of allocated and released memory through dynamic instrumentation;

[0121] The CPU execution time is calculated by the difference between the execution start time and the end time, which helps evaluate the impact of defects on program performance.

[0122] After dynamic verification is completed, the collected runtime data is characterized and processed to extract dynamic features that are helpful for defect assessment, including:

[0123] Execution exception characteristics: extract exception types, such as null pointer exceptions and illegal access exceptions; extract the number of exceptions to reflect the frequency and stability of defect triggering.

[0124] Path coverage feature: The calculated path coverage is used as a feature to characterize the code execution during the dynamic verification process; the higher the coverage, the more representative the dynamic verification result is.

[0125] Performance consumption characteristics: Extract memory consumption and CPU execution time as important indicators to measure the program running status.

[0126] As an option, feature extraction tools (such as Python data processing libraries) can be used to standardize runtime data, remove redundant data, and ensure that the extracted dynamic features are representative and usable.

[0127] In this embodiment, the extracted runtime features are associated with the candidate defect paths to generate a defect verification data set including dynamic verification results.

[0128] Specifically, based on the code locations of candidate defect paths, the extracted dynamic features are associated with the corresponding paths to form a structured defect verification dataset.

[0129] Exemplarily, the record contents of the defect verification data set include:

[0130] Defect path location: file path and code line number;

[0131] Dynamic features: exception type, number of exceptions, path coverage, memory consumption, CPU execution time, etc.;

[0132] Static Association: Associate with defect types and features in static analysis results.

[0133] It should be noted that the generated defect verification dataset will serve as the basic data input for subsequent feature fusion and defect assessment, providing dynamic verification support for the machine learning model and further improving the accuracy of defect assessment.

[0134] Reference Figure 4 ,S3: Fusion of the static analysis results with the dynamic ,verification data to form a defect assessment feature vector;,S3.1: Preprocessing the static analysis results ,features including code complexity, module dependency, defect type and rule identification;

[0135] S3.2: Perform feature preprocessing on dynamic verification data. Dynamic features include execution anomaly features, path coverage features, and performance index features.

[0136] S3.3: Perform data standardization on static and dynamic features;

[0137] S3.4: perform feature fusion on the standardized static features and dynamic features;

[0138] S3.5: Filter the features with high contribution in the fused feature vector for input into the subsequent defect assessment model.

[0139] Specifically, this step preprocesses, standardizes and fuses static and dynamic features, and finally selects features with high contribution, providing high-quality feature input for subsequent defect assessment models to ensure the accuracy and robustness of the assessment results.

[0140] In this embodiment, feature preprocessing is performed on the static analysis results, and the features include code complexity, module dependency, defect type, and rule identification.

[0141] Specifically, the extraction and preprocessing process of static features includes:

[0142] Code complexity: Code complexity is used to measure the complexity of the code logic path and reflect the risk level of potential defects. The cyclomatic complexity of the code is calculated through static analysis tools. Specifically, the code control flow graph is analyzed to extract information such as the number of code branches, conditional judgments, and loop structures.

[0143] For example, when there are multiple if-else branches or nested loops in the code path, the complexity will increase significantly.

[0144] Module dependencies: Extract the calling relationships between code modules, including cross-module function calls, dependency chain length, etc.; use static analysis tools to generate module dependency graphs and record the calling paths between modules. For example, A→B→C means that module A depends on module B, and module B depends on module C.

[0145] Defect type and rule identification: Extract defect type labels and rule identification based on the rule matching results provided by the static analysis tool; defect types include security issues, performance issues, and dependency issues. For example, null pointer access is a security issue, and unreleased resources are performance issues.

[0146] As an option, static features can be vectorized to convert features such as code complexity, module dependencies, and defect types into numerical data for subsequent fusion processing.

[0147] In this embodiment, feature preprocessing is performed on the dynamic verification data, and the dynamic features include execution anomaly features, path coverage features, and performance index features.

[0148] Specifically, the preprocessing of dynamic features includes: Execution exception features: Extract the exception types and exception occurrence times captured during the dynamic verification process, such as null pointer exceptions, memory out-of-bounds exceptions, etc.; the number of exceptions reflects the frequency of defect triggering, and the exception type identifies the specific nature of the defect. For example, the more null pointer exceptions, the wider the impact of the defect. Path coverage features: During the dynamic verification process, the code coverage of the defective path is counted; the path coverage is calculated, expressed as the ratio of the number of executed code lines to the total number of lines. The higher the value, the higher the coverage of the defective path by the test case. Performance indicator features: Extract the performance consumption of the program during runtime, including memory usage, CPU execution time, etc.;

[0149] Memory usage is monitored by dynamic instrumentation to monitor the total amount of memory allocated and released, and CPU execution time is calculated by the difference between the program start time and end time.

[0150] It should be noted that, in some embodiments, the dynamic features may be extended according to different verification environments. For example, in a distributed system, indicators such as network delay and throughput may also be included.

[0151] In this embodiment, data standardization is performed on static features and dynamic features.

[0152] The purpose of data standardization is to eliminate the inconsistency of different feature data dimensions and ensure that the features are fused at the same numerical scale.

[0153] In a possible implementation, a minimum-maximum normalization method is used for numerical features to map the data to the [0,1] interval, specifically including: first, calculating the minimum and maximum values ​​of each feature; then, normalizing the original feature values.

[0154] For example, the code complexity in static features and the memory consumption in dynamic features can be mapped to the same numerical range through standardization to prevent a feature value that is too large or too small from affecting subsequent model training.

[0155] In this embodiment, feature fusion is performed on the standardized static features and dynamic features.

[0156] The purpose of feature fusion is to organically combine static analysis results with dynamic verification data to form a complete defect assessment feature vector.

[0157] In this embodiment, fusion is achieved by feature splicing, that is, the standardized static feature vector and the dynamic feature vector are spliced ​​into a unified feature vector F.

[0158] In some embodiments, different features can be weighted by means of feature weighted fusion to reflect the contribution of each feature to defect assessment. For example, a higher weight can be given to the number of anomalies in dynamic features, giving priority to the defect triggering frequency.

[0159] In this embodiment, features with high contribution in the fused feature vector are screened and used as input for the subsequent defect assessment model.

[0160] In order to improve the training efficiency and accuracy of the evaluation model, redundant features are removed and features with high contribution are screened out.

[0161] Specifically, feature importance analysis methods, such as tree model-based feature importance calculation or correlation-based feature screening methods, are used to determine the contribution of features to the defect assessment task.

[0162] For example, a preliminary random forest model can be trained to calculate the weight of each feature, and features with lower weights can be eliminated, retaining feature vectors with high contribution for subsequent model input.

[0163] It should be noted that the results of feature screening will vary depending on the feature distribution of the actual project. Users can dynamically adjust the screening threshold based on experimental verification to ensure the high quality and representativeness of the input features.

[0164] Reference Figure 5,S4: Input the defect assessment feature vector into the machine learning model to evaluate the authenticity and severity of the defect;S4.1: Perform data segmentation on the defect assessment feature vector and divide the data set into a training set, a validation set and a test set, where the training set is used for model training, the validation set is used for hyperparameter adjustment, and the test set is used for model performance evaluation;

[0165] S4.2: Select a machine learning model as the defect assessment model, which is an XGBoost model based on a gradient boosting decision tree;

[0166] S4.3: Model training for defect assessment feature vector;

[0167] S4.4: Adjust the hyperparameters of the XGBoost model using the validation set, including the learning rate, maximum tree depth, and subsample ratio.

[0168] S4.5: Input the test set into the trained XGBoost model and output the defect authenticity and severity prediction results, where:

[0169] The authenticity of the defect is determined by the classification probability. When the classification probability is greater than the threshold θ, it is determined to be a real defect. The severity of the defect is quantified by the prediction score, and the output range is between 0 and 1. The higher the prediction score, the more serious the defect.

[0170] Specifically, this step achieves accurate assessment of software defects by reasonably dividing the data set, selecting a suitable machine learning model for training and verification, and outputting the authenticity judgment and severity quantitative score of the defects based on the evaluation results.

[0171] In this embodiment, data segmentation is performed on the defect assessment feature vector, and the data set is divided into a training set, a verification set, and a test set.

[0172] Specifically, the input defect assessment feature vector contains static analysis features and dynamic verification features. Through data segmentation, the scientific nature and generalization ability of model training, verification and testing are ensured:

[0173] Training set: used to train the machine learning model. During the training process, the model learns the mapping relationship between input features and labels;

[0174] Validation set: used to adjust model hyperparameters, prevent overfitting, and improve the generalization performance of the model;

[0175] Test set: used to evaluate the final trained model and verify the performance of the model on unknown data.

[0176] As an option, you can split the data using a proportional partitioning method, for example:

[0177] The original data set is divided into a training set, a validation set, and a test set in a ratio of 70%:15%:15%. In another implementation, the division ratio can be adjusted according to the data volume and project requirements, for example, the training set ratio can be appropriately increased when the data volume is small.

[0178] It should be noted that in order to ensure the balance of data distribution, data division can be performed through random sampling or stratified sampling to ensure that the defect types and severity label distributions in different data sets are as consistent as possible.

[0179] In this embodiment, a machine learning model is selected as the defect assessment model, and the model is an XGBoost model based on a gradient boosting decision tree.

[0180] Specifically, the XGBoost model is an integrated learning algorithm based on an improved version of the gradient boosting decision tree. It has a high training speed and generalization ability and is suitable for large-scale feature data and complex evaluation tasks.

[0181] XGBoost gradually optimizes the prediction error of the model by iteratively building multiple weak decision trees;

[0182] The goal of each tree is to fit the residual of the previous iteration, minimize the objective function through the gradient descent method, and the final model is the weighted sum of multiple trees;

[0183] In this embodiment, the input of XGBoost is the defect assessment feature vector, and the output is the prediction results of the authenticity and severity of the defect.

[0184] Specifically, the training process includes the following steps:

[0185] Initialize model parameters: Initialize the parameters of the XGBoost model, such as the number of trees, learning rate, maximum depth, etc., based on the input feature vector and label data;

[0186] Iterative training: Through the training set data, several weak decision trees are iteratively constructed. The goal of each iteration is to minimize the loss function:

[0187] The loss function of the model includes prediction error and regularization term, where the regularization term is used to control the complexity of the model and prevent overfitting;

[0188] The leaf node weights of each tree are updated by gradient descent to optimize the model output.

[0189] Training labels: Defect authenticity label: the value is 0 (non-real defect) or 1 (real defect); Defect severity label: the value range is 0 to 1, indicating the severity of the defect.

[0190] For example, during the training process, the XGBoost model automatically handles missing feature values ​​and supports mixed input of categorical and numerical features to ensure the stability and effectiveness of training.

[0191] In this embodiment, the hyperparameters of the XGBoost model are adjusted through the validation set, and the hyperparameters include the learning rate, the maximum depth of the tree, and the sub-sample ratio.

[0192] Specifically, the validation set is used to optimize the hyperparameters of the XGBoost model. The main parameters adjusted include: learning rate: controls the step size of each iteration. A smaller learning rate can improve model accuracy but increase training time; maximum tree depth: controls the depth of each tree. Too large a depth will lead to overfitting, while too small a depth will lead to underfitting; subsample ratio: controls the sample ratio used in each iteration to reduce the risk of overfitting.

[0193] Hyperparameter adjustment is performed using grid search or random search methods, for example: training the model under different hyperparameter combinations; selecting the optimal hyperparameter combination through performance indicators of the validation set (such as accuracy, F1 score).

[0194] In this embodiment, the test set is input into the trained XGBoost model, and the defect authenticity and severity prediction results are output.

[0195] Defect authenticity: The XGBoost model outputs the classification probability of each defect. When the classification probability is greater than the preset threshold θ, it is judged as a real defect;

[0196] For example, when the classification probability is 0.8 and the threshold θ=0.5, the defect is determined to be a real defect.

[0197] Defect severity:

[0198] The XGBoost model outputs a predicted score for the defect, ranging from 0 to 1, with higher scores indicating a higher severity of the defect;

[0199] For example, an output score of 0.9 indicates that the defect has a high severity and needs to be fixed as a priority.

[0200] It should be noted that the classification probability threshold θ can be adjusted according to actual needs to balance the recall rate and false alarm rate of the model. For example, in scenarios with high security requirements, the threshold θ can be lowered to improve the detection coverage of defects.

[0201] S5: Output defect detection report.

[0202] Embodiment 2:

[0203] Reference Figure 6In a second embodiment of the present invention, the present invention provides a software integration evaluation system based on machine learning and static analysis, the system comprising:

[0204] Static analysis module, used to perform static scanning on software source code, detect potential defects and extract static features;

[0205] Specific features include:

[0206] Rule base configuration: Load security rules, performance rules, and module dependency rules to ensure that static analysis tools can detect different types of defects.

[0207] Code scanning: Use static analysis tools (such as SonarQube, CodeQL, etc.) to statically scan the source code and output preliminary defect results, including defect type, code location, etc.

[0208] Static feature extraction: Extract static features such as code complexity, module dependencies, and defect descriptions to form static analysis results.

[0209] Data deduplication and preprocessing: Deduplication and filtering of scan results to ensure the uniqueness and accuracy of the candidate defect list.

[0210] Dynamic verification module, used to perform dynamic verification based on candidate defect paths of static analysis, collect runtime data and extract dynamic features;

[0211] Specific features include:

[0212] Test case generation:

[0213] The automated testing tool generates unit test cases to cover the defect paths marked by static analysis;

[0214] Manually supplement integration test cases, suitable for complex cross-module defect path verification.

[0215] Dynamic verification execution: Use dynamic instrumentation tools (such as Valgrind, Pin, etc.) to execute test cases, dynamically verify candidate defect paths, and monitor runtime behavior.

[0216] Runtime data collection: collects performance indicators such as exception information, path coverage, memory consumption, and CPU execution time during program runtime.

[0217] Dynamic feature extraction: Extract dynamic features such as the number of execution exceptions, path coverage, and performance indicators to provide input data for feature fusion.

[0218] The feature fusion module is used to fuse the static analysis results with the dynamic verification data to form a defect assessment feature vector;

[0219] Specific features include:

[0220] Feature preprocessing: Standardize static features and dynamic features separately to ensure consistent data dimensions.

[0221] Feature fusion: Static features (such as code complexity and module call relationships) and dynamic features (such as the number of exceptions, coverage and performance indicators) are combined to form a unified feature vector.

[0222] Feature screening: Through feature importance analysis methods, we can screen features with high contribution, eliminate redundant features, and improve model training efficiency and evaluation accuracy.

[0223] The machine learning assessment module is used to assess the authenticity and severity of defects using machine learning models based on defect assessment feature vectors;

[0224] Specific features include:

[0225] Data segmentation: Divide the feature vector dataset into training set, validation set, and test set to ensure the scientific nature of model training and evaluation.

[0226] Model selection and training: The XGBoost model based on gradient boosting decision tree is used to train the model to learn the mapping relationship between defect features and labels.

[0227] Hyperparameter optimization: Adjust the model’s hyperparameters based on the validation set, including learning rate, tree depth, and subsample ratio, to optimize model performance.

[0228] Defect Assessment Output:

[0229] Defect authenticity: Determine whether the defect is real based on the classification probability output by the model;

[0230] Defect severity: The severity of the defect is quantified through the regression output score of the model, ranging from 0 to 1, with higher values ​​indicating more severe defects.

[0231] The report generation module is used to automatically generate software defect detection reports.

[0232] Specific features include:

[0233] Defect location information: Report the specific location of the defect in the source code, including the file path and code line number.

[0234] Defect type and description: Displays the type, nature, and risk description of the defect, such as null pointer exception, resource leakage, etc.

[0235] Severity score: Based on the prediction results of the machine learning model, it provides a severity score for the defect to help developers reasonably arrange the repair priority.

[0236] Repair suggestions and sample code: Combine the rule base and defect type to provide targeted repair solutions and code examples.

[0237] Report format output: supports PDF, HTML and JSON format output, combined with graphical tools to display module dependency diagrams and defect propagation paths.

[0238] Embodiment 3

[0239] The third embodiment of the present invention is based on the same inventive concept. The present invention proposes a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the steps of a software integration evaluation method based on machine learning and static analysis in the above-mentioned embodiment.

[0240] Embodiment 4

[0241] The fourth embodiment of the present invention is based on the same inventive concept. The present invention proposes a computer device, a computer device including: a processor, a memory; the processor and the memory communicate with each other; the memory is used to store instructions; the processor is used to execute the instructions in the memory, and executes a software integration evaluation method based on machine learning and static analysis of the above embodiment.

[0242] It should be understood that the various parts of the present invention can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiments, a plurality of steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0243] Finally, it should be noted that the above is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the aforementioned embodiments, it is still possible for those skilled in the art to modify the technical solutions described in the aforementioned embodiments or to make equivalent substitutions for some of the technical features therein. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A software integration evaluation method based on machine learning and static analysis, characterized in that: The following steps are involved: S1: Perform static analysis on the software source code to generate a list of candidate defects; S2: Based on the candidate defect list, perform dynamic verification and collect runtime data; S3: Fusing the static analysis results with the dynamic verification data to form a defect assessment feature vector; S4: Inputting the defect assessment feature vector into a machine learning model to assess the authenticity and severity of the defect; S5: Output defect detection report.

2. The software integration evaluation method based on machine learning and static analysis according to claim 1, characterized in that: The S1 step further includes: S1.1: configuring a rule base of a static analysis tool, wherein the rule base includes security rules, performance rules, and module dependency rules; S1.2: Scan the software source code using static analysis tools to obtain preliminary defect detection results; S1.3: De-duplicate the preliminary defect detection results, remove duplicate defects in the same code position, and retain a unique defect record; S1.4: Extracting static features of defects based on a code static feature extraction algorithm, wherein the static features include code complexity, inter-module calling relationships, and defect descriptions; S1.5: Clustering and filtering the extracted static features, clustering the defects based on feature similarity to form a final candidate defect list, wherein the feature similarity is calculated using the cosine similarity formula, specifically: Where A and B are the feature vectors of the defect, and n is the dimension of the feature.

3. A software integration evaluation method based on machine learning and static analysis according to claim 2, characterized in that: The code complexity in S1.4 is calculated by the cyclomatic complexity formula, specifically: C=E-N+2P Where C is the cyclomatic complexity, E is the number of edges in the program, N is the number of nodes in the program, and P is the number of connected subgraphs in the program.

4. The software integration evaluation method based on machine learning and static analysis according to claim 1, characterized in that: The S2 step further includes: S2.1: Automatically generate test cases for the candidate defect list, wherein the test cases include unit tests and integration tests. Unit tests are generated by automated testing tools, and integration tests are implemented by manual supplementary design. S2.2: Execute the generated test cases and use Valgrind to dynamically verify the defect path; S2.3: Collecting runtime data during the dynamic verification process, wherein the runtime data includes execution exception data, path coverage data, and performance indicator data; S2.4: performing feature extraction on the collected runtime data; S2.5: Associate the extracted runtime features with the candidate defect paths to generate a defect verification dataset containing dynamic verification results for subsequent feature fusion and defect assessment.

5. The software integration evaluation method based on machine learning and static analysis according to claim 1, characterized in that: The S3 step further includes: S3.1: Perform feature preprocessing on the static analysis results, wherein the features include code complexity, module dependency, defect type, and rule identification; S3.2: Perform feature preprocessing on the dynamic verification data, wherein the dynamic features include execution anomaly features, path coverage features, and performance index features; S3.3: performing data standardization processing on the static features and the dynamic features; S3.4: perform feature fusion on the standardized static features and dynamic features; S3.5: Filter the features with high contribution in the fused feature vector for input into the subsequent defect assessment model.

6. The software integration evaluation method based on machine learning and static analysis according to claim 1, characterized in that: The S4 step further includes: S4.1: Perform data segmentation on the defect assessment feature vector, and divide the data set into a training set, a validation set, and a test set, wherein the training set is used for model training, the validation set is used for hyperparameter adjustment, and the test set is used for model performance evaluation; S4.2: Select a machine learning model as a defect assessment model, wherein the model is an XGBoost model based on a gradient boosting decision tree; S4.3: Performing model training on the defect assessment feature vector; S4.4: adjusting the hyperparameters of the XGBoost model through the validation set, wherein the hyperparameters include learning rate, maximum depth of the tree, and subsample ratio; S4.5: Input the test set into the trained XGBoost model and output the defect authenticity and severity prediction results, where: The authenticity of the defect is determined by the classification probability, and when the classification probability is greater than a threshold value θ, it is determined to be a real defect; The severity of the defect is quantified by a prediction score, and the output range is between 0 and 1. The higher the prediction score, the more severe the defect.

7. The software integration evaluation method based on machine learning and static analysis according to claim 4 is characterized in that: The execution exception data in S2.3 includes the exception type and the number of exception occurrences; The path coverage data is calculated by the following formula: The CoveredLines is the number of code lines covered by the test execution, and the TotalLines is the total number of code lines on the defect path.

8. A software integration evaluation system based on machine learning and static analysis, characterized in that: A software integration evaluation method based on machine learning and static analysis as described in any one of claims 1 to 7, wherein the system comprises: Static analysis module, used to perform static scanning on software source code, detect potential defects and extract static features; Dynamic verification module, used to perform dynamic verification based on candidate defect paths of static analysis, collect runtime data and extract dynamic features; The feature fusion module is used to fuse the static analysis results with the dynamic verification data to form a defect assessment feature vector; The machine learning assessment module is used to assess the authenticity and severity of defects using machine learning models based on defect assessment feature vectors; The report generation module is used to automatically generate software defect detection reports.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, it implements a software integration evaluation method based on machine learning and static analysis as described in any one of claims 1 to 7.

10. A readable storage medium, characterized in that: The readable storage medium stores a computer program, and when the computer program is executed by a processor, the method for software integration evaluation based on machine learning and static analysis as described in any one of claims 1 to 7 is implemented.

Images