Test method for predicting Bug number of software version based on neural network

Abstract

The invention provides a test method for predicting the Bug number of a software version based on a neural network, and belongs to the technical field of software engineering and software test management. Indexes are extracted from historical data such as demand scale and complexity, code change frequency, development cycle, test resource investment, test personnel experience and coverage, and a training sample is generated in combination with multi-platform data association and field aperture unification; the method comprises the following steps of: performing normalization and PCA dimension reduction on a sample, dividing a training set and a test set, constructing a neural network containing ReLU and Dropout, and performing parameter adjustment training with EarlyStopping and ReduceLROnPlatau through K-fold cross validation; features are generated for new iteration according to the same preprocessing process, the number of predicted defects is output, and a basis is provided for testing resource configuration and use case priority in cooperation with a Web interface.

Description

Technical Field

[0001] This invention belongs to the field of software engineering and software testing management technology, and in particular relates to a testing method for predicting the number of bugs in a software version based on neural networks. Background Technology

[0002] In traditional software testing practices, the prediction of the number of version defects often relies on the tester's experience or simple statistical estimation, such as linear estimation based on the number of new lines of code and the experience defect rate. This type of approach easily ignores dynamic factors such as requirement complexity and differences in developer capabilities, resulting in a large prediction deviation.

[0003] On the other hand, key data affecting the number of defects are usually scattered across multiple platforms such as requirements documents, code repositories, and defect management systems. The testing team needs to manually export tables and manually merge and clean them. Due to inconsistent field definitions (for example, "code change volume" may be measured by the number of lines changed, the number of files, or the number of commits), it is easy to generate correlation errors and is time-consuming, making it difficult to quickly obtain usable conclusions in frequent iterations.

[0004] Furthermore, fixed formulas or static rule-driven methods (such as "base coefficient × code change volume + historical average number of defects") are difficult to characterize non-linear relationships, such as the interaction between requirement complexity and test resource investment, which leads to further expansion of errors under complex architectures and complex business scenarios.

[0005] In agile iteration scenarios, traditional data collection and manual analysis often take a long time. By the time the prediction results are output, the iteration version may have already entered the test execution phase. The prediction conclusions are difficult to use to guide the adjustment of test case priorities and resource allocation, thus affecting the efficiency of defect detection. Summary of the Invention

[0006] In view of this, the present invention aims to propose a testing method for predicting the number of bugs in a software version based on a neural network, so as to at least solve one of the problems in the background art.

[0007] To achieve the above objectives, the technical solution of the present invention is implemented as follows: A testing method for predicting the number of bugs in a software version based on a neural network includes: S1. Obtain historical data corresponding to the target iteration version. The historical data comes from at least the requirements management system, code repository, and defect management system. Generate version association records for the target iteration version. The version association records include at least a version identifier and a set of requirements items, a set of code changes, and a set of defect records associated with the version identifier. S2. Based on preset field mapping and unit conversion rules, perform field standardization on the indicator fields in the set of requirement items, code change set and defect record set, and perform consistency verification; when the verification fails, output a list of fields to be reviewed or correct abnormal fields using preset correction rules; S3. Construct feature sets for the Bug introduction dimension and the Bug discovery dimension respectively. The feature set for the Bug introduction dimension shall include at least one or more of the following indicators: requirement scale and complexity, code change frequency, development cycle, or code quality. The feature set for the Bug discovery dimension shall include at least one or more of the following indicators: test resource investment, test coverage and frequency, test method diversity, or test environment investment. Based on the Bug introduction dimension feature set and the Bug discovery dimension feature set, construct cross-combination features. The cross-combination features are used to characterize the coupling influence between the introduction factor and the discovery factor. S4. Perform data preprocessing on the Bug introduction dimension feature set, Bug discovery dimension feature set and cross-combination feature set. The data preprocessing includes at least one or more of missing value processing, normalization and dimensionality reduction to obtain model input features. S5. Construct a dual-branch neural network model, which includes a Bug introduction branch sub-network and a Bug discovery branch sub-network. Each sub-network receives model input features corresponding to its dimension, and the outputs of the two branches are weighted and fused through a gated fusion layer to obtain a fused representation. S6. Based on the fusion representation, the predicted number of bugs in the target iteration version is output through the counting output layer, wherein the counting output layer adopts a non-negative constraint to make the output non-negative, and the dual-branch neural network model is trained based on the counting loss function. S7. Divide the samples into training and testing sets, and use cross-validation to determine the optimal combination of at least one of the following: number of network layers, number of neurons, learning rate, or regularization parameter; during training, use an early stopping strategy and an adaptive learning rate adjustment strategy to control the number of training rounds. S8. Repeat steps S1 to S4 to obtain the input features to be predicted for the new iteration version to be predicted, and input them into the trained dual-branch neural network model to obtain the predicted number of bugs; obtain the prediction interval based on multiple inference samplings including the Dropout layer; output the predicted number of bugs and the prediction interval for test resource allocation.

[0008] Furthermore, the standardization of field definitions includes converting different definitions of code change amount into a unified definition, wherein the different definitions include at least two or three of the following: number of lines of code, number of changed files, and number of commits.

[0009] Furthermore, the consistency verification includes: performing non-empty verification and time range verification on the number of requirement items, code change records, and defect records under the same version identifier; when the time range is inconsistent, truncate or remove records that exceed the time window according to the preset version time window.

[0010] Furthermore, the cross-combination features include at least one or more of the following: the product of requirement complexity and test coverage, the product of code change frequency and test resource investment, and the product of development cycle and test frequency.

[0011] Furthermore, the data preprocessing includes scaling the features to a preset range using min-max normalization and performing dimensionality reduction using principal component analysis to extract the main feature components.

[0012] Furthermore, both the Bug introduction branch subnetwork and the Bug discovery branch subnetwork include at least one fully connected layer and a Dropout layer. The gated fusion layer generates corresponding weights based on the outputs of the two branches and performs a weighted summation of the branch outputs.

[0013] Furthermore, the counting loss function is a Poisson negative log-likelihood loss or an equivalent counting regression loss, so that the model training objective matches the counting attribute of the number of bugs.

[0014] Furthermore, the prediction interval is obtained by performing multiple forward inferences on the same input to obtain multiple bug count prediction values, and is calculated based on the quantiles of the multiple bug count prediction values.

[0015] Furthermore, this solution discloses a testing system for predicting the number of bugs in a software version based on a neural network, including: a data acquisition module, a field caliber unification and consistency verification module, a feature construction module, a data preprocessing module, a model training module, and a prediction output module; wherein, the feature construction module is used to construct a feature set for the bug introduction dimension and a feature set for the bug discovery dimension respectively and generate cross-combined features; the model training module is used to train a dual-branch neural network model including a bug introduction branch sub-network, a bug discovery branch sub-network, and a gated fusion layer, and outputs the predicted bug number value using a non-negative constraint counting output layer; the prediction output module is used to output the predicted bug number value and the prediction interval and provide a result display for test resource allocation.

[0016] Furthermore, this solution discloses a computer-readable storage medium having a computer program stored thereon, the computer program implementing the method when executed by a processor.

[0017] Compared with existing technologies, the testing method for predicting the number of bugs in a software version based on a neural network, as described in this invention, has the following advantages: (1) This invention introduces side indicators such as demand scale and complexity, code change frequency, etc., and incorporates them together with side indicators such as test resource investment, test personnel experience, coverage and frequency into the feature set, avoiding the use of a single code volume or historical average for estimation, and reducing the systematic bias caused by the omission of key variables in experience estimation from the perspective of information coverage. (2) By performing normalization and PCA dimensionality reduction on the data and reasonably dividing the training set and test set, this invention can reduce the differences in field dimensions and redundant information, while making the model training more stable; and by introducing Dropout to suppress overfitting in the parameter tuning stage, and combining K-fold cross-validation to select a more robust combination of hyperparameters, the generalization ability of the model under different iteration versions and different project forms can be improved. (3) The present invention uses strategies such as EarlyStopping and ReduceLROnPlateau to dynamically control the training process during the training process, which can shorten the training and update cycle without adding extra manual analysis burden, making the prediction more in line with the agile iteration rhythm; at the same time, combined with the Web interface to provide prediction services, the testing team can quickly obtain prediction results without mastering complex modeling details, thereby adjusting manpower and test case priorities earlier. Attached Figure Description

[0018] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a schematic diagram of the method described in an embodiment of the present invention. Detailed Implementation

[0019] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0020] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this invention, unless otherwise stated, "a plurality of" means two or more.

[0021] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art will understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0022] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0023] The following description uses an example of an implementation method for predicting the number of defects in an iterative version. This embodiment is not limited to a specific development language or framework; it can be deployed as a service component of a test management platform or independently as a prediction service. Its core lies in constructing two types of indicators according to a unified standard, completing preprocessing, training a neural network, and providing predictive output for the new iteration.

[0024] In a feasible engineering implementation, the first step is to establish an "iteration version identifier" as a cross-platform association primary key, denoted as sprint_id or release_id. This identifier can come from the iteration number in the iteration planning system, the version release tag, or the FixVersion field in the defect system. Around this identifier, data is collected from the requirement side, the code side, and the defect side: Requirement-side data can include the number of stories, the scale of requirement points (e.g., the number of requirement items or the sum of story points), and the complexity of requirements (e.g., requirement priority distribution, the number of modules involved, the number of interface changes, etc.); code-side data can be extracted from repositories such as Git, containing the commit set corresponding to sprint_id, with fields including at least commit_id, author, commit time, number of changed files, number of changed lines (added_lines, deleted_lines, net_lines), and the association number with the requirement or defect; defect-side data can be extracted from systems such as JIRA, containing newly created / closed defect records within the scope of this sprint_id or FixVersion, with fields including at least issue_key, severity level, creation / closure time, whether it was reopened due to regression, and the module to which it belongs. The actual number of defects y in this iteration version is then calculated as a supervised learning label. To address the issue of inconsistent field definitions, this embodiment predefines field mapping and conversion rules. For example, multiple sources of "code change volume" are uniformly mapped to two standard fields: `change_lines` and `change_commits`. When a system only provides the number of files or commits, it is still retained as `change_files` or `change_commits` and used as an independent feature in subsequent modeling, avoiding forced conversion during the data collection phase that could lead to error propagation. When multiple repositories or submodules exist in the same iteration, the summation or averaging is performed by `sprint_id`, while auxiliary features such as `repo_count` and `module_count` are recorded to reflect version span. These processes reduce the risk of errors in manual merging and association of multi-source data and provide a reusable data foundation for subsequent automated training.

[0025] After completing data collection and correlation, a feature set X is constructed around the "defect introduction dimension" and the "defect discovery dimension." The introduction dimension can include at least: requirement scale and complexity, code change frequency, development cycle, overall skill level of the development team, and overall code quality; the discovery dimension can include at least: testing resource investment, tester professional experience, test coverage and execution frequency, test method diversity, and the number of test environments deployed. For ease of reproduction, this embodiment provides a set of directly applicable field examples: the introduction dimension fields can be set as req_count (number of requirement items) and req_story_points (story...). The discovery dimension fields can be set as follows: total points, req_complex_score (complexity score calculated based on requirement priority and number of modules involved), change_commits (number of commits during the iteration), change_lines (net or total number of lines of change), change_files (number of changed files), dev_team_exp_avg (average experience months of the development team), dev_turnover (proportion of developers changing during the iteration), iteration_days (iteration days), static_issue_density (density of static issues), etc.; discovery dimension fields can be set as qa_person_days (testing man-days invested), qa_exp_avg (average experience months of the testing team), case_count (number of test cases), exec_rounds (regression rounds), automation_ratio (percentage of automated test cases), coverage_rate (coverage rate), env_count (number of test environments), test_method_count (number of method categories used, such as functional / performance / security / compatibility, etc.). The above fields are not exhaustive. Actual projects can add or delete them based on data availability, but both dimensions should be covered simultaneously to express the technical approach of "extracting key indicators from two dimensions" emphasized in the disclosure document.

[0026] Data preprocessing is then performed. For missing values, different strategies can be adopted depending on the field type: for count fields (such as change_commits, case_count), missing values ​​can be set to 0 or the historical median of the item, and a missing value indicator field (such as change_commits_isnull) can be added to retain missing information; for ratio fields (such as automation_ratio, coverage_rate), missing values ​​can be set to the historical mean of the item and truncated to [0,1]; obvious outliers can be truncated by quantiles or corrected by 3 times the standard deviation. After cleaning, all numerical features are normalized to [0,1] using MinMaxScaler to reduce the impact of different units on the training process; when the feature dimension is high or there is strong correlation, PCA is further used for dimensionality reduction, retaining the main information while removing redundant features, and the resulting Scaler and PCA parameters are persistently saved for subsequent use on new iteration data to perform the same preprocessing chain, ensuring consistency between training and inference. Finally, the processed sample set is divided into training and testing sets according to a preset ratio, such as by time sequence (training with earlier iterations and testing with newer iterations) to better reflect real-world deployment scenarios.

[0027] In terms of model construction, this embodiment uses a neural network to perform regression prediction on the preprocessed feature vectors. The basic structure may include: the number of nodes in the input layer is consistent with the output dimension of PCA; one or more hidden layers are set, each with several neurons and ReLU activation is used to fit the nonlinear relationship; Dropout layers are inserted between the hidden layers to reduce overfitting; the output layer is set to a single neuron to output the predicted number of defects. Considering that the number of defects is a non-negative count, in this embodiment, the output layer may further use non-negative constrained activation (e.g., ReLU or Softplus) to ensure that the output is not negative; in an optional implementation, a loss function that fits the count distribution better (e.g., interpreting the output as the mean of a Poisson distribution and minimizing the corresponding negative log-likelihood) may also be used to improve the fitting ability for scenarios with "small number of defects but significant fluctuations". In addition to the single-path structure mentioned above, to better align with the business semantics of "two-dimensional metrics," the input features can be divided into two groups based on the introduction and discovery dimensions, respectively, and input into two sub-networks to obtain representation vectors h_in and h_out. These vectors are then concatenated and interaction terms are constructed (e.g., element-wise multiplication yields h_cross = h_in ⊙ h_out). Finally, [h_in, h_out, h_cross] is input into the subsequent fully connected layer to obtain the final output. This approach can explicitly express the situation described in the disclosure document where "requirement complexity and testing investment have a cross-influence," avoiding being replaced by simple linear rules.

[0028] During the parameter tuning and training phases, this embodiment searches for or compares combinations of hyperparameters such as the number of network layers, the number of neurons per layer, the Dropout ratio, the learning rate, and the number of dimensions retained in PCA. K-fold cross-validation is used to evaluate the model's stability and generalization ability, thus selecting the configuration that performs more stably in multi-fold validation. During training, an EarlyStopping callback is introduced to monitor the validation set loss, stopping training early if the loss does not decrease over a long period to avoid overfitting. Simultaneously, a ReduceLROnPlateau callback is introduced to automatically reduce the learning rate when the validation loss plateaus, resulting in a finer convergence process. After training is complete, the model is evaluated using a test set, and the final model parameters and preprocessing parameters are saved.

[0029] In practical application, the system reads the latest iteration data and generates feature vectors following the same process as the training phase: using sprint_id as the primary key, it retrieves fields such as the known requirement scale, code changes, and test deployment plans from the requirements, code, and defect system (or test management system). After field mapping, cleaning, normalization, and PCA transformation, the data is input into the model to obtain the predicted defect count ŷ. To enhance the usability of the prediction results for test resource decisions, an optional implementation can use a "multiple random inactivation inference" method to estimate uncertainty: Dropout is enabled during the inference phase, and the same feature vector is inferred N times to obtain {ŷ_1…ŷ_N}. The mean of these inferences is used as the final predicted value, and the quantiles (such as the 5th and 95th percentiles) are used as the prediction interval to prompt test managers to reserve buffers in resource allocation. Finally, a web interface is provided as a unified entry point: it supports selecting or uploading CSV data by iteration version to trigger prediction, displays the predicted defect count, optional prediction intervals, key input fields, and data integrity prompts, and writes the prediction results back to the test management platform to assist in test case prioritization and manpower scheduling.

[0030] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A testing method for predicting the number of bugs in a software version based on a neural network, characterized in that, include: S1. Obtain historical data corresponding to the target iteration version. The historical data comes from at least the requirements management system, code repository, and defect management system. Generate version association records for the target iteration version. The version association records include at least a version identifier and a set of requirements items, a set of code changes, and a set of defect records associated with the version identifier. S2. Based on preset field mapping and unit conversion rules, perform field standardization on the indicator fields in the set of requirement items, code change set and defect record set, and perform consistency verification; when the verification fails, output a list of fields to be reviewed or correct abnormal fields using preset correction rules; S3. Construct feature sets around the Bug introduction dimension and the Bug discovery dimension respectively, and construct cross-combination features based on the Bug introduction dimension feature set and the Bug discovery dimension feature set. The cross-combination features are used to characterize the coupling effect between the introduction factor and the discovery factor. S4. Perform data preprocessing on the Bug introduction dimension feature set, Bug discovery dimension feature set and cross-combination feature to obtain the model input features; S5. Construct a dual-branch neural network model, which includes a Bug introduction branch sub-network and a Bug discovery branch sub-network. Each sub-network receives model input features corresponding to its dimension, and the outputs of the two branches are weighted and fused through a gated fusion layer to obtain a fused representation. S6. Based on the fusion representation, the predicted number of bugs in the target iteration version is output through the counting output layer, wherein the counting output layer adopts a non-negative constraint to make the output non-negative, and the dual-branch neural network model is trained based on the counting loss function. S7. Divide the samples into training and testing sets, and use cross-validation to determine the optimal combination of at least one of the following: number of network layers, number of neurons, learning rate, or regularization parameter; during training, use an early stopping strategy and an adaptive learning rate adjustment strategy to control the number of training rounds. S8. Repeat steps S1 to S4 to obtain the input features to be predicted for the new iteration version to be predicted, and input them into the trained dual-branch neural network model to obtain the predicted number of bugs; obtain the prediction interval based on multiple inference samplings including the Dropout layer; output the predicted number of bugs and the prediction interval for test resource allocation.

2. The method according to claim 1, characterized in that, The standardization of field definitions includes converting different definitions of code change amount into a unified definition. The different definitions include at least two or three of the following: number of lines of code, number of changed files, and number of commits.

3. The method according to claim 1, characterized in that, The consistency verification includes: performing non-empty verification and time range verification on the number of requirement items, code change records and defect records under the same version identifier; when the time range is inconsistent, records exceeding the time window are truncated or removed according to the preset version time window.

4. The method according to claim 1, characterized in that, The cross-combination features include at least one or more of the following: the product of requirement complexity and test coverage, the product of code change frequency and test resource investment, and the product of development cycle and test frequency.

5. The method according to claim 1, characterized in that, The data preprocessing includes scaling the features to a preset range using min-max normalization and performing dimensionality reduction using principal component analysis to extract the main feature components.

6. The method according to claim 1, characterized in that, Both the Bug Introducing Branch Subnetwork and the Bug Discovery Branch Subnetwork include at least one fully connected layer and a Dropout layer. The gated fusion layer generates corresponding weights based on the outputs of the two branches and performs a weighted summation of the branch outputs.

7. The method according to claim 1, characterized in that, The counting loss function is Poisson negative log-likelihood loss or its equivalent counting regression loss, so that the model training objective matches the counting attribute of the number of bugs.

8. The method according to claim 1, characterized in that, The prediction interval is obtained by performing multiple forward inferences on the same input to obtain multiple bug count prediction values, and then calculating the quantiles of the multiple bug count prediction values.

9. A testing system for predicting the number of bugs in a software version based on a neural network, characterized in that, include: The system comprises a data acquisition module, a field caliber unification and consistency verification module, a feature construction module, a data preprocessing module, a model training module, and a prediction output module. The feature construction module constructs feature sets for both the bug introduction dimension and the bug discovery dimension, generating cross-combined features. The model training module trains a dual-branch neural network model containing a bug introduction branch sub-network, a bug discovery branch sub-network, and a gated fusion layer, and outputs the predicted bug count using a non-negative constraint counting output layer. The prediction output module outputs the predicted bug count and prediction range, and provides a result display for test resource allocation.

10. A computer-readable storage medium having a computer program stored thereon, the computer program, when executed by a processor, implementing the method of any one of claims 1 to 8.

Images