A software defect prediction method, device and electronic equipment

Abstract

Embodiments of the present application provide a software defect prediction method and device and electronic equipment. The method is applied to an electronic equipment, and comprises: obtaining an expected first cumulative defect quantity in a software testing process; predicting a first testing time length based on the first cumulative defect quantity and a pre-obtained software defect prediction model; the first testing time length is a time length required for the cumulative defect quantity found in the software testing process to be the first cumulative defect quantity; wherein the software defect prediction model is obtained based on test data, and the software defect prediction model is used to reflect a growth rule of the cumulative defect quantity in the software testing process with an increase of the testing time length; the test data comprises cumulative defect quantities under a plurality of first testing workloads, and each cumulative defect quantity is generated in a first testing workload testing process of the software. The method can improve the problem that the growth rule of the cumulative defect quantity found in the software testing process predicted by the Gompertz model with an increase of the testing time length is inaccurate.

Description

Technical Field

[0001] This application belongs to the field of software testing, and specifically relates to a software defect prediction method, device, and electronic device. Background Technology

[0002] Before a software is released to the market, extensive internal testing is conducted to prevent internal defects from escaping to users' production environments, thereby improving the software's quality.

[0003] In software testing, to achieve the best return on investment in terms of cost and software quality, a software defect prediction model based on the Gompertz model is typically used to predict the relationship between the number of defects found and the testing time. This curve can estimate the total number of defects that can be predicted during testing and the remaining testing time, thus allowing for the development of a reasonable cost plan and improving the return on investment between software testing costs and final software quality. However, existing software defect prediction models based on the Gompertz model have specific preconditions for practical use: firstly, the testing resources invested throughout the testing activity need to remain relatively stable; secondly, the tested components need to remain identical; and thirdly, the number of testing rounds should be no less than three. Because multiple projects may run concurrently during software testing, and testing resources need to be switched between projects as needed, the invested testing resources cannot be consistently allocated, and the tested components cannot remain identical. This leads to inaccurate predictions by the Gompertz model-based software defect prediction model regarding the cumulative number of defects found during testing as the testing time increases. Summary of the Invention

[0004] Therefore, the purpose of this application is to provide a software defect prediction method, apparatus, and electronic device to improve the problem that the prediction of the cumulative number of defects found during software testing as a result of increasing test duration is inaccurate by the Gompertz model.

[0005] The embodiments of this application are implemented as follows: In a first aspect, embodiments of this application provide a software defect prediction method, the method comprising: obtaining a first cumulative number of defects expected during software testing; predicting a first test duration based on the first cumulative number of defects and a pre-acquired software defect prediction model; the first test duration being the time required for the cumulative number of defects discovered during software testing to equal the first cumulative number of defects; wherein the software defect prediction model is obtained based on test data fitting, the software defect prediction model being used to reflect the growth law of the cumulative number of defects during software testing as the test duration increases, the test data including multiple cumulative number of defects under a specified first test workload, each cumulative number of defects being generated by the software during the first test workload test of the specified test workload.

[0006] In implementing this application, the applicant discovered that the software defect prediction model implemented using the Gompertz model has clear preconditions for use in actual prediction. However, it is difficult to keep the invested test resources relatively stable in actual prediction. Since the software defect prediction model obtained in advance in this application is based on fitting test data, and since the test data contains multiple cumulative defect numbers, each of which is generated by the software during the first test workload test, the invested test workload increases steadily. Therefore, the software defect prediction model obtained based on fitting test data can overcome the impact of unstable test resource investment during the test process. Thus, based on the software defect prediction model and the first cumulative defect number, the accuracy of the predicted first test duration is higher.

[0007] In one possible implementation of the first aspect embodiment, the method further includes: obtaining the current testing progress of the software, and obtaining a second cumulative defect number based on the first cumulative defect number and the current testing progress; correspondingly, predicting the first testing duration based on the first cumulative defect number and a pre-acquired software defect prediction model, including: predicting the second testing duration based on the second cumulative defect number and the pre-acquired software defect prediction model, wherein the second testing duration is the time required for the cumulative number of defects discovered during the software testing process to reach the second cumulative defect number.

[0008] In this embodiment of the application, in order to ensure that the actual prediction process is not affected by the instability of test resource input, and at the same time to ensure that the actual prediction process is not affected by the different test objects, a second number of defects is obtained based on the current test progress and the first cumulative number of defects, which is not affected by the instability of test resource input and the different test objects. Therefore, the accuracy of the predicted second test duration based on the software defect prediction model and the second cumulative number of defects is higher.

[0009] In one possible implementation of the first aspect embodiment, software testing includes branch testing and main line testing of the software. Obtaining the current testing progress of the software includes: obtaining the workload percentage of the branch tests, the workload percentage of the main line tests, the current testing progress of the branch tests, and the current testing progress of the main line tests; and obtaining the current testing progress based on the workload percentage of the branch tests, the workload percentage of the main line tests, the branch test progress, and the main line test progress.

[0010] In this embodiment, the software testing process is divided into a branch testing phase and a main testing phase. The branch testing phase tests each functional module of the software individually, while the main testing phase tests multiple functional points of the software uniformly. The branch testing phase and the main testing phase together constitute the overall testing phase of the software. Therefore, by obtaining the current testing progress through the proportion of branch testing workload, the proportion of main testing workload, the progress of branch testing, and the progress of main testing, the calculation of the second cumulative defect count is not affected by the different test objects, making the calculated second defect count more accurate.

[0011] In one possible implementation of the first aspect embodiment, the current test progress is the sum of a first product and a second product; the first product is the product of the branch test progress and the branch test percentage, and the second product is the product of the main line test progress and the main line test percentage.

[0012] In this embodiment, the first product guarantees the test progress of the branch test, the second product represents the test progress of the main line test, and the sum of the first product and the second product is the current test progress. Using the first product and the second product to calculate the current test progress can more accurately calculate the current test progress.

[0013] In one possible implementation of the first aspect embodiment, the test duration is positively linearly correlated with the amount of test work invested. After calculating the second test duration, the method further includes: obtaining the current test workload, which represents the total amount of test work invested in testing the software up to the present, and the unit test workload, which represents the amount of test work invested per unit test duration; and obtaining the remaining test workload based on the second test duration, the current test workload, and the unit test workload, wherein the remaining test workload represents the amount of work required to reach the second cumulative number of defects discovered during the software testing process.

[0014] In this embodiment, since the duration of software testing is positively linearly correlated with the amount of testing work invested, in short, the amount of testing work invested is the same for each interval of the same testing duration. By obtaining the current cumulative testing workload and the unit testing workload, it is possible to accurately calculate the amount of work required to reach the second cumulative number of defects discovered during the software testing process, thereby improving the ability of testers to plan test work and improving the efficiency of test work.

[0015] In one possible implementation of the first aspect embodiment, after calculating the second cumulative defect count, the method further includes: obtaining the current cumulative defect count, wherein the current cumulative defect count is the total number of defects found during the current testing of the software; and obtaining the current software testing task completion rate based on the current cumulative defect count and the second cumulative defect count, wherein the software testing task in the software testing process is the number of defects found during the software testing process that is close to reaching the second cumulative defect count.

[0016] In this embodiment, since the second cumulative defect count is the predicted total number of defects to be found in the software, the current software testing task completion rate is obtained based on the current cumulative defect count and the second defect count. This can provide testers with an accurate reference for formulating work plans and improve the efficiency of software testing.

[0017] In one possible implementation of the first aspect embodiment, before using the software defect prediction model, the method further includes acquiring a first dataset, the first dataset comprising N sets of first test data, each set of first test data containing the cumulative number of defects under a first testing workload, where N is a positive integer greater than 2; fitting the software defect prediction model with unknown parameters using multiple sets of first test data in the first dataset to determine the unknown parameters in the parameters of the software defect prediction model; wherein, the independent variable of the software defect prediction model is the testing duration, the dependent variable of the software defect prediction model expression is the cumulative number of defects, and the testing duration and the testing workload invested are positively linearly correlated.

[0018] In this embodiment of the application, the first test workload in each group of the first test data is within a preset range, indicating that the test workload invested at the same interval of test duration is average. The software defect prediction model with unknown parameters is fitted using multiple first test data in the first dataset to determine the unknown parameters in the software defect prediction model parameters. This software defect prediction model can overcome the impact of unstable test resource investment during the testing process, making the predicted test duration more accurate.

[0019] In one possible implementation of the first aspect embodiment, obtaining the first dataset includes: obtaining a second dataset periodically recorded during software testing; wherein the second dataset contains M groups of second test data, each group of second test data including a third cumulative number of defects and a second test workload within the corresponding period; merging multiple groups of second test data in the second dataset whose test workload is less than the first test workload; and / or, splitting a group of second test data whose test workload is greater than the first test workload into multiple groups to obtain the first dataset; wherein... The number of third defects in the first dataset is obtained by merging and / or splitting the number of fourth defects in the second dataset, the first test workload in the second dataset is obtained by merging and / or splitting the second test workload in the second test dataset, the sum of the number of third defects in N groups is equal to the sum of the number of fourth defects in M ​​groups, and the sum of the first test workload in N groups is equal to the sum of the second test workload in M ​​groups.

[0020] In this embodiment, since test data is recorded periodically during software testing, the test resources invested in each period may fluctuate. In order to ensure that the test resources invested in each period are average, it is necessary to merge and / or split the N first test datasets in the first dataset to obtain a second test dataset including M second test data. The workload of the second test in each group of second test data is within a preset range. The second dataset is fitted to determine more reasonable software defect prediction model parameters, so that the software defect prediction model has a stronger ability to overcome the impact of unstable test resource investment during the testing process.

[0021] Secondly, embodiments of this application provide a software defect prediction device, the device comprising: an acquisition module, configured to acquire a first cumulative defect number expected during software testing; and a processing module, configured to predict a first test duration based on the first cumulative defect number and a pre-acquired software defect prediction model; wherein the first test duration is the time required for the cumulative number of defects discovered during software testing to reach the first cumulative defect number; wherein the software defect prediction model is obtained based on test data fitting, the software defect prediction model is used to reflect the growth law of the cumulative defect number during software testing as the test duration increases, and the test data includes the cumulative defect number under multiple first test workloads, each cumulative defect number being generated by the software during the first test workload test.

[0022] Thirdly, embodiments of this application provide an electronic device, the electronic device including a processor and a memory, the processor being coupled to the memory, the processor being configured to execute a computer program stored in the memory to implement the methods provided by any possible implementation of the first aspect embodiments and / or in combination with the first aspect embodiments.

[0023] It should be understood that the second and third aspects of the embodiments of the present invention are consistent with the technical solutions of the first and second aspects of the embodiments of the present invention, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be described again.

[0024] Other features and advantages of this application will be set forth in the following description. The objectives and other advantages of this application can be realized and obtained through the structures specifically pointed out in the written description and the accompanying drawings. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the embodiments will be briefly described below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. The above and other objects, features, and advantages of this application will become clearer through the accompanying drawings.

[0026] Figure 1 A flowchart illustrating a software defect prediction method provided in an embodiment of this application is shown.

[0027] Figure 2 A schematic diagram of a data processing method provided in an embodiment of this application is shown.

[0028] Figure 3 A flowchart illustrating a software defect prediction method provided in an embodiment of this application is shown.

[0029] Figure 4 The diagram shows a schematic representation curve of a software defect prediction model provided in an embodiment of this application.

[0030] Figure 5 The illustration shows a schematic diagram of a method for obtaining the current test progress according to an embodiment of this application.

[0031] Figure 6 A schematic diagram of the structure of a software defect prediction device provided in an embodiment of this application is shown.

[0032] Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0033] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. The following embodiments are provided as examples to more clearly illustrate the technical solutions of this application, and should not be used to limit the scope of protection of this application. Those skilled in the art will understand that, without conflict, the following embodiments and features can be combined with each other.

[0034] It should be noted that similar reference numerals and letters in the following figures denote similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, relational terms such as "first," "second," etc., in the description of this application are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one…" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0035] Furthermore, the term "and / or" in this application is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0036] Given that existing software defect prediction models based on the Gompertz model suffer from inaccuracies in predicting the growth pattern of the cumulative number of defects discovered during software testing as test duration increases, this application provides a novel software defect prediction method to address this issue. This method utilizes multiple test data sets containing the cumulative defect counts under multiple first test workloads for fitting, determining the unknown parameters in the software defect prediction model, and obtaining a defect prediction model that accurately reflects the growth pattern of the cumulative number of defects as test duration increases. The accuracy of the first test duration obtained based on this software defect prediction model and the acquired first cumulative defect count is significantly higher.

[0037] The following will combine Figure 1 This application describes the method for obtaining a software defect prediction model.

[0038] Step S101: Obtain the first dataset. In this embodiment, the first dataset includes N sets of first test data. Each set of first test data contains the cumulative number of defects under the first test workload, where N is a positive integer greater than 2. The first test workload in each set of first test data is positively linearly correlated with the test duration. In short, the test workload invested at intervals of the same test duration is average. Please refer to Table 1, which presents a first dataset.

[0039] Table 1

[0040] Table 1 shows the cumulative number of defects discovered at 20 person-day intervals. Since the testing workload invested at the same interval is average, the workload invested in 20 person-days is equivalent to the same testing duration. A person-day is a unit of measurement for workload. It represents the working time and workload spent by one person in one day. A person-day consists of two parts: Person: refers to the number of personnel involved in the work; Day: refers to the time spent on the work, usually calculated in working days or actual working hours.

[0041] In one implementation, the first dataset can be obtained by directly downloading a pre-processed first dataset from a database, and then using the first dataset to aggregate the unknown parameters of the software defect prediction model.

[0042] In another implementation, the first dataset can be obtained by: obtaining a second dataset periodically recorded during software testing; wherein the second dataset contains M sets of second test data, each set of second test data containing the third cumulative number of defects and the second test workload within the corresponding period; merging multiple sets of second test data in the second dataset whose test workload is less than the first test workload; and / or splitting a set of second test data whose test workload is greater than the first test workload to obtain the first dataset; wherein the third number of defects in the first dataset is obtained by merging and / or splitting the fourth number of defects in the second dataset, the first test workload in the second dataset is obtained by merging and / or splitting the second test workload in the second test dataset, the sum of the N sets of third number of defects is equal to the sum of the M sets of fourth number of defects, and the sum of the N sets of first test workload is equal to the sum of the M sets of second test workload.

[0043] In this implementation, testers typically acquire test data periodically during software testing to obtain a second dataset, as shown in Table 2. Table 2 illustrates one such second dataset. Table 2 contains 20 sets of second test data, where N is 20.

[0044] Table 2

[0045] Table 2 shows that 20 testing cycles have been conducted to date, identifying 268 defects. However, the workload of the second set of tests in each cycle is not evenly distributed. For example, only one person-day was allocated in cycle 1, while ten person-days were allocated in cycle 10. Clearly, the workload allocated in each cycle of the second set of tests is unstable. Therefore, the second set of tests needs to be processed to ensure that the workload allocated by testers in each cycle of the dataset used for fitting is stable. For example... Figure 2 As shown, Figure 2 The process of processing the second dataset shown in Table 2 to obtain the first dataset is illustrated.

[0046] In this process, as of now, the second dataset reflects that the software testing process has already invested 244 person-days of testing work. Now, testers need to specify the first testing workload required for each cycle based on the existing testing situation in the second dataset (the first testing workload can be a range or a specific value, which can be set according to the needs, and is not limited here). Figure 2 The first test workload specified in the document is 6-14 person-days, which is understandable. Ultimately, the workload for each cycle is expected to be close to 10 person-days, with a fluctuation of no more than 4 person-days.

[0047] In Table 2, if the testing workload for several consecutive periods is less than 10 person-days (e.g., periods 1 through 4 all have less than 10 person-days), the second test data for periods 1, 2, 3, and 4 can be merged by default. Conversely, if the testing workload for several periods in Table 2 is greater than 15 person-days, the second test data for those periods can be split evenly. After processing the second dataset using the above method, the first dataset is obtained as shown in Table 3. The resulting second dataset contains 24 sets of first test data, where M is 24.

[0048] Table 3

[0049] The periods in the second dataset of Table 2 with a second test workload of less than 10 person-days are merged, and / or the periods in the second dataset with a second test workload of more than 15 person-days are divided equally to obtain the first dataset in Table 3, so that the workload input of each period in the first dataset of Table 3 is basically close to 10 person-days.

[0050] Step S102: Use multiple first test data in the first dataset to fit the software defect prediction model with unknown parameters, and determine the unknown parameters in the software defect prediction model.

[0051] In this embodiment of the application, the software defect prediction model is a software defect prediction model based on the Gompertz model, and its expression is: ,in, The independent variable is denoted as , representing the test duration. Let be the dependent variable, representing the test duration during software testing. The cumulative number of defects discovered over time; for The maximum value of indicates that when The total number of defects that may be found when the value approaches infinity; hour hour initial value, The range of values ​​is ; For shape parameters, The larger the value, the slower the reliability increases, until a limit is reached. The larger the value, the longer the testing time required for the software. The unknown parameters of the software defect prediction model in this application are: , , As long as the correct calculation can be performed based on the first test data in the first dataset. , , The trend of the number of defects found during the software testing process will closely match the Gompertz growth model, so the total number of software defects can be predicted by using the Gompertz limit prediction and arrival time.

[0052] During the process of utilizing the first test data in the first dataset, the cumulative number of defects in the first test data is used as... Input value, first test workload as Input values. Furthermore, the method for fitting the software defect prediction model using the first dataset can be either the three-sum method or the nonlinear least squares method. The specific fitting process involves using existing function fitting software that supports the aforementioned three-sum method and nonlinear least squares method. This is current technology and will not be elaborated upon here.

[0053] By fitting the software defect prediction model with unknown parameters using multiple first test data points from the first dataset, the unknown parameters in the software defect prediction model were determined. This resulted in a software defect prediction model capable of overcoming the impact of unstable test resource allocation during the testing process. This software defect model... This value can predict the total number of defects in the software, as well as the testing time required to find them. Testers can then use this result to develop a reasonable test plan, improving the return on investment between software testing costs and the final quality of the software.

[0054] The following will combine Figure 3 This is an impromptu description of a software defect prediction method provided in the embodiments of this application. The focus of these embodiments is on how to use the software defect prediction model obtained from steps S101-S102. And obtain... Figure 3 The software defect prediction method described herein can be executed by electronic devices, such as mobile phones, computers, servers, etc., without limitation.

[0055] Step S201: Obtain the expected first cumulative number of defects during the software testing process.

[0056] In this embodiment, the first cumulative defect count is the product of the maximum value of the software testing model and the preset target defect detection rate. The maximum value of the software testing model can be understood as the expression of the software defect prediction model. In The value represents when The total number of defects that may be found when the value approaches infinity, but the testing time. It cannot be infinite, and defects in software cannot be found 100%. Therefore, a target defect detection rate needs to be set. The target defect detection rate can be 95% or 90%, and you can set it yourself. There are no restrictions here.

[0057] The following is combined Figure 4 A detailed analysis of the process for obtaining the first cumulative defect count.

[0058] like Figure 4 As shown, Figure 4 The expression for the software defect prediction model is as follows: , The value is 503.3715, predicting a total of 503 defects. If the target defect detection rate is 95%, the first cumulative number of defects is 478.

[0059] Step S202: Based on the first cumulative number of defects and the pre-acquired software defect prediction model, predict the first test duration.

[0060] In this embodiment of the application, the first test duration is the time required for the cumulative number of defects discovered during the software testing process to reach the first cumulative number of defects. The software defect prediction model is obtained by fitting test data. The software defect prediction model is used to reflect the growth law of the cumulative number of defects during the software testing process as the test duration increases. The test data includes the cumulative number of defects under multiple first test workloads. Each cumulative number of defects is generated by the software during the first test workload test.

[0061] like Figure 4 The expression for the software defect prediction model in the text is: The corresponding curve, since the first cumulative defect count is 478, when When it is 478, the corresponding The value is 68, which means that it takes 68 cycles to find 478 defects.

[0062] As one possible implementation, the software defect prediction method further includes: obtaining the current testing progress of the software, and obtaining a second cumulative defect number based on a first cumulative defect number and the current testing progress; correspondingly, predicting a first testing duration based on the first cumulative defect number and a pre-acquired software defect prediction model, including: predicting a second testing duration based on the second cumulative defect number and the pre-acquired software defect prediction model.

[0063] In this embodiment, the second test duration is the time required for the cumulative number of defects discovered during software testing to reach a second cumulative defect count. This process overcomes the impact of the non-identity of the tested objects during testing, thereby predicting a more accurate number of defects in the software and the time required to discover them.

[0064] Software testing includes branch testing and mainline testing. Branch testing involves testing multiple functional points in the software separately, while mainline testing involves combining multiple functional points into the mainline for testing. The test objects and testing methods used in branch testing and mainline testing are different. Therefore, it is necessary to combine the current testing progress to predict the number of defects in the software and the testing time required to find the corresponding defects.

[0065] For example, such as Figure 4 The expression for the software defect prediction model in the text is: The corresponding curve, assuming the current testing progress is 88.3% and the first cumulative defect count is 478, predicts the second cumulative defect count to be 478 / 88.3% = 506. The value is 77, which means that it takes 77 cycles to find 506 defects.

[0066] In one implementation, the current test progress of the software can be obtained by performing a test using a preset progress testing software.

[0067] In another implementation, the method for obtaining the current testing progress of the software can be: obtaining the workload percentage of branch tests, the workload percentage of main tests, the testing progress of the current branch test, and the testing progress of the current main test; and obtaining the current testing progress based on the workload percentage of branch tests, the workload percentage of main tests, the progress of branch tests, and the progress of main tests.

[0068] In this implementation, the branch testing workload percentage is the ratio of the pre-planned testing workload required in the branch testing phase to the total workload required for the entire software testing phase; the mainline testing workload percentage is the ratio of the pre-planned testing workload required in the mainline testing phase to the total workload required for the entire software testing phase; the branch testing progress is the completion rate of the testing work currently in the branch testing phase; and the mainline testing progress is the completion rate of the testing work currently in the mainline testing phase. Figure 5 As shown, assuming the pre-planned workload for branch testing is 859 person-days and the pre-planned workload for mainline testing is 2661.5 person-days, the ratio of branch testing workload to mainline testing workload during the testing process is 1:3.1, that is, branch testing accounts for 24.4% and mainline testing accounts for 75.6%. A total of 67 functional points need to be tested in the branch testing phase. Currently, 47 functional points have been tested, that is, the branch testing progress is 62.69%. The mainline testing is scheduled to start in the 11th week of 2023, but it has not yet started, so the mainline testing progress is 0%. Based on the above branch testing workload ratio, mainline testing workload ratio, branch testing progress, and mainline testing progress, the current testing progress is 15.3%.

[0069] The principle behind calculating the current test progress—based on the percentage of workload for branch tests, the percentage of workload for main line tests, the progress of branch tests, and the progress of main line tests—is the sum of a first product and a second product. The first product is the product of the branch test progress and the percentage of workload for branch tests, and the second product is the product of the main line test progress and the percentage of workload for main line tests. Based on this principle, the specific formula for calculating the current test progress is: 62.69% * 24.4% + 0 = 15.3%.

[0070] As one possible implementation, the software defect prediction method further includes: obtaining the current test workload, which represents the total test workload invested in testing the software up to the present, and the unit test workload, which represents the test workload invested per unit test duration; and obtaining the remaining test workload based on the second test duration, the current test workload, and the unit test workload, wherein the remaining test workload represents the amount of work required to reach the second cumulative defect number from the cumulative number of defects discovered during the software testing process.

[0071] In this implementation, since the duration of software testing is positively linearly correlated with the amount of testing work invested, in short, the amount of testing work invested is the same for each interval of the same testing duration. By obtaining the current cumulative testing workload and the unit testing workload, the remaining workload can be accurately calculated, thereby improving the testers' ability to plan testing work and increasing testing efficiency.

[0072] As one possible implementation, the software defect prediction method further includes: obtaining the current cumulative number of defects, wherein the current cumulative number of defects is the total number of defects found during the current testing of the software; and obtaining the current software testing task completion rate based on the current cumulative number of defects and the second cumulative number of defects, wherein the software testing task in the software testing process is the distance between the cumulative number of defects found in the software testing process and the second cumulative number of defects.

[0073] In this implementation, since the second cumulative defect count is the predicted total number of defects to be found in the software, the current software testing task completion rate is obtained based on the current cumulative defect count and the second defect count. This can provide testers with an accurate reference for formulating work plans and improve the efficiency of software testing.

[0074] Please participate Figure 6 Based on the same inventive concept, this application also provides a software defect prediction device 100, which includes: an acquisition module 110 and a processing module 120.

[0075] The acquisition module 110 is used to acquire the expected first cumulative number of defects during the software testing process.

[0076] The processing module 120 is used to predict a first test duration based on a first cumulative defect count and a pre-acquired software defect prediction model. The first test duration is the time required for the cumulative number of defects discovered during the software testing process to reach the first cumulative defect count. The software defect prediction model is obtained by fitting test data and is used to reflect the growth pattern of the cumulative defect count during the software testing process as the test duration increases. The test data includes the cumulative defect counts under multiple first test workloads, and each cumulative defect count is generated by the software during the first test workload test.

[0077] Optionally, the processing module 120 is further configured to obtain the current testing progress of the software, and obtain a second cumulative defect number based on the first cumulative defect number and the current testing progress; accordingly, based on the first cumulative defect number and a pre-acquired software defect prediction model, predict the first testing duration, including: based on the second cumulative defect number and the pre-acquired software defect prediction model, predict the second testing duration, wherein the second testing duration is the time required for the cumulative number of defects discovered during the software testing process to reach the second cumulative defect number.

[0078] Optionally, software testing includes branch testing and mainline testing of the software. The processing module 120 is specifically used to obtain the workload percentage of branch testing, the workload percentage of mainline testing, the testing progress of the current branch testing, and the testing progress of the current mainline testing; and to obtain the current testing progress based on the workload percentage of branch testing, the workload percentage of mainline testing, the branch testing progress, and the mainline testing progress.

[0079] Optionally, the principle for calculating the current test progress is: the sum of the first product and the second product; the first product is the product of the branch test progress and the branch test percentage, and the second product is the product of the main line test progress and the main line test percentage.

[0080] Optionally, the processing module 120 is further configured to: obtain the current test workload, which represents the total test workload invested in testing the software up to the present, and the unit test workload, which represents the test workload invested within a unit test duration; and obtain the remaining test workload based on the second test duration, the current test workload, and the unit test workload, wherein the remaining test workload represents the amount of work required to reach the second cumulative defect number from the cumulative number of defects discovered during the software testing process.

[0081] Optionally, the processing module 120 is further configured to obtain the current cumulative number of defects, wherein the current cumulative number of defects is the total number of defects found during the current testing of the software; based on the current cumulative number of defects and the second cumulative number of defects, the current software testing task completion rate is obtained, and the software testing task in the software testing process is the number of defects found during the software testing process that is close to reaching the second cumulative number of defects.

[0082] Optionally, the processing module 120 is further configured to acquire a first dataset, which includes N sets of first test data, each set of first test data containing the cumulative number of defects under the first test workload, where N is a positive integer greater than 2; and to fit a software defect prediction model with unknown parameters using multiple sets of first test data in the first dataset to determine the unknown parameters in the software defect prediction model; wherein the independent variable of the software defect prediction model is the test duration, the dependent variable of the software defect prediction model expression is the cumulative number of defects, and the test duration and the test workload invested are positively linearly correlated.

[0083] Optionally, the processing module 120 is specifically used to obtain a second dataset periodically recorded during the software testing process; wherein, the second dataset contains M sets of second test data, each set of second test data containing the third cumulative number of defects and the second test workload within the corresponding period; merging multiple sets of second test data in the second dataset whose test workload is less than the first test workload; and / or, splitting a set of second test data whose test workload is greater than the first test workload to obtain a first dataset; wherein, the third number of defects in the first dataset is obtained by merging and / or splitting the fourth number of defects in the second dataset, the first test workload in the second dataset is obtained by merging and / or splitting the second test workload in the second test dataset, the sum of the N sets of third number of defects is equal to the sum of the M sets of fourth number of defects, and the sum of the N sets of first test workload is equal to the sum of the M sets of second test workload.

[0084] like Figure 7 As shown, Figure 7 This diagram illustrates a structural block diagram of an electronic device 200 provided in an embodiment of this application. The electronic device 200 includes: a transceiver 210, a memory 220, a communication bus 230, and a processor 240.

[0085] The transceiver 210, memory 220, and processor 240 are electrically connected directly or indirectly to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses 230 or signal lines. The transceiver 210 is used to send and receive data. The memory 220 is used to store computer programs, such as... Figure 5The software functional module shown is the software defect prediction device 100. The software defect prediction device 100 includes at least one software functional module that can be stored as software or firmware in the memory 220 or embedded in the operating system (OS) of the electronic device 200. The processor 240 is used to execute executable modules stored in the memory 220, such as the software functional module or computer program included in the software defect prediction device 100. For example, the processor 240 is used to execute... Figure 3 The method shown.

[0086] The memory 220 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0087] Processor 240 may be an integrated circuit chip with signal processing capabilities. The aforementioned processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), a microprocessor, etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. Alternatively, processor 240 can also be any conventional processor.

[0088] Among them, the aforementioned electronic devices 200 include, but are not limited to, mobile phones, computers, servers, etc.

[0089] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0090] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0091] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0092] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A software defect prediction method, characterized in that, The method includes: Obtain the expected first cumulative number of defects during the software testing process; where software testing includes branch testing and mainline testing of the software; Obtain the current testing progress of the software, wherein the current testing progress is the sum of a first product and a second product; the first product is the product of the current testing progress of the branch test and the workload percentage of the branch test, and the second product is the product of the current testing progress of the main test and the workload percentage of the main test. Based on the first cumulative defect count and the current test progress, a second cumulative defect count is obtained; Based on the second cumulative number of defects and the pre-acquired software defect prediction model, the second test duration is predicted, wherein the second test duration is the time required for the cumulative number of defects discovered during the software testing process to reach the second cumulative number of defects. The software defect prediction model is obtained by fitting multiple first test data in a first dataset. The software defect prediction model is used to reflect the growth pattern of the cumulative number of defects in the software testing process as the testing time increases. The first test data includes the cumulative number of defects under multiple first test workloads, and each cumulative number of defects is generated by the software during the first test workload test. The first dataset is obtained by merging multiple sets of second test data in a second dataset whose test workload is less than the target test workload; and / or by splitting a set of second test data whose test workload is greater than the target test workload. The second dataset is obtained by periodically recording during the software testing process.

2. The method according to claim 1, characterized in that, The test duration is positively linearly correlated with the amount of testing work involved. After calculating the second test duration, the method further includes: Get the current test workload, which represents the total test workload invested in testing the software up to now, and the unit test workload, which represents the test workload invested per unit test duration. Based on the second test duration, the current test workload, and the unit test workload, the remaining test workload is obtained. The remaining test workload represents the amount of work that still needs to be invested to reach the second cumulative defect number from the cumulative number of defects discovered during the software testing process.

3. The method according to claim 1, characterized in that, After calculating the second cumulative defect count, the method further includes: Obtain the current cumulative number of defects, wherein the current cumulative number of defects is the total number of defects found during the current testing of the software; Based on the current cumulative number of defects and the second cumulative number of defects, the current software testing task completion rate is obtained. The software testing task in the software testing process is the number of defects found during the software testing process that is close to reaching the second cumulative number of defects.

4. The method according to claim 1, characterized in that, Before using the software defect prediction model, the method further includes: Obtain the first dataset, which includes N sets of first test data. Each set of first test data contains the cumulative number of defects under the first test workload, where N is a positive integer greater than 2. The unknown parameters in the software defect prediction model are determined by fitting multiple test data from the first dataset to the software defect prediction model. The independent variable of the software defect prediction model is the test duration, the dependent variable of the software defect prediction model expression is the cumulative number of defects, and the test duration is positively linearly correlated with the amount of testing work invested.

5. The method according to claim 4, characterized in that, The second dataset contains M sets of second test data, each set of second test data including the cumulative number of defects in the corresponding period and the second test workload; The number of third defects in the first dataset is obtained by merging and / or splitting the number of fourth defects in the second dataset, the first test workload in the first dataset is obtained by merging and / or splitting the second test workload in the second test dataset, the sum of the number of third defects in N groups is equal to the sum of the number of fourth defects in M ​​groups, and the sum of the first test workload in N groups is equal to the sum of the second test workload in M ​​groups.

6. A software defect prediction device, characterized in that, The device includes: The acquisition module is used to acquire the expected first cumulative number of defects during the software testing process; where software testing includes branch testing and mainline testing of the software. The processing module is used to obtain the current testing progress of the software, obtain a second cumulative defect number based on the first cumulative defect number and the current testing progress, and predict a second testing duration based on the second cumulative defect number and a pre-acquired software defect prediction model. Wherein, the current test progress is the sum of the first product and the second product; the first product is the product of the current test progress of the branch test and the workload ratio of the branch test, and the second product is the product of the current test progress of the main test and the workload ratio of the main test. The second test duration is the time required for the cumulative number of defects discovered during the software testing process to reach the second cumulative number of defects. The software defect prediction model is obtained by fitting multiple first test data in the first dataset. The software defect prediction model is used to reflect the growth pattern of the cumulative number of defects in the software testing process as the testing time increases. The first test data includes the cumulative number of defects under multiple first test workloads, and each cumulative number of defects is generated by the software during the first test workload test. The first dataset is obtained by merging multiple sets of second test data in the second dataset whose test workload is less than the target test workload; and / or by splitting a set of second test data whose test workload is greater than the target test workload. The second dataset is obtained by periodically recording during the software testing process.

7. An electronic device, characterized in that, The electronic device includes at least one processor and a memory connected to the at least one processor, the at least one processor being configured to execute a computer program in the memory to implement the steps of the method as described in any one of claims 1-5.

Images