A software fault number detection method, a detection system, a storage medium and an application

Abstract

The application belongs to the technical field of software fault data identification, and discloses a software fault number detection method, a detection system, a storage medium and an application. In the established software fault detection or repair model, the total number of faults is taken as a parameter of the cumulative detected fault number m(t), m(t) is compared with the cumulative detected fault number in the real failure data set (fitting and prediction), so as to indirectly indicate the accuracy of the total number of faults. On the basis of a large number of early-stage analyses, the application mainly focuses on the influence of a(t) on the SRGM model, mainly analyzes the modeling and evaluation of a(t), observes the changes in reliability caused by different a(t) through the establishment of a unified imperfect debugging model, and then measures the performance difference of various a(t). The application has the disturbance influence of different forms of a(t) describing the new fault introduction ability on the SRGM model.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of software fault data identification, and particularly relates to a software fault number detection method, a detection system, a storage medium, equipment and application. BACKGROUND

[0002] Under the driving of the accelerated evolution of new generation information communication technology, the software industry is developing rapidly, software is given new missions, and humans have greater expectations for the functions of software. Correspondingly, the evolution of the form of software has been further enriched, and single machine version, network version, mobile version, large-scale online shopping software platform, large-scale online open course learning platform, large-scale social platform, large-scale communication platform and open source software have emerged in an endless stream. In particular, cloud computing, big data, the Internet of Things, artificial intelligence, blockchain and metaverse have accelerated the evolution of the era of "software defining everything". Software has become a tool and a starting point for people in more and more fields such as learning, production and life. Large complex software, industrial software, numerical calculation and simulation software (especially Matlab, CAD, CAE, etc.), security software, operating systems and database software have become "neck-stiffening" bottlenecks that need to be broken through. The role of the software industry in the national economy and social development is becoming more and more important, so the quality of software, especially the reliability attribute, must be given enough attention. In the face of these new changes and trends, more attention has been paid to the defects and quality problems of software, and its reliability, safety and stability have become the focus of attention. Reliability is an important component of many non-quality attributes of software and the basis for software credibility and security. Software, as an artificial product, basically goes through the stages of demand analysis, outline design, detailed design, coding, testing, deployment and application before being released to the market or provided to users. In this process, defects caused by internal design or programming errors are inevitably introduced, making reliability an important factor affecting software quality. Therefore, the analysis of software reliability has always been an important theoretical content of computer or software engineering and a problem that needs to be continuously optimized and improved in software basic theory and engineering analysis.

[0003] With large complex software as an example, it is easy to know that the software must be tested and modified for a certain period before release, and only when the release criteria are met can the release be carried out. Due to the complexity of software structure, the randomness of the test process and other uncertain factors, especially the widespread existence of imperfect bug fixing phenomenon, the total number of faults in the software has strong random variability. The total number of faults in the software (marked as a(t) in the invention) is an unknown variable, how to reduce the total number of faults as much as possible in the test phase, and then improve the software reliability, is an important topic in the field of enhancing the quality of software itself. In-depth analysis of the total number of faults a(t) in the software has important theoretical significance and practical value for improving reliability, evaluating software testing cost, and predicting software release time.

[0004] In current software reliability analysis, there is a lack of theory for analyzing the total number of faults in software alone, and there are few direct analysis documents, which also makes it difficult to seek reliability improvement from the perspective of analyzing the total number of faults. Software reliability can be modeled, measured and evaluated with the help of mathematical models, among which software reliability growth model (SRGM) is an important tool. The modeling of SRGM cannot be separated from the participation of the total number of faults in the software, and a(t) is an essential parameter, which has been confirmed in many model analyses. The total number of faults a(t) in the software is a description of the quality of the software, and the change in its quantity can also describe the introduction of new faults in bug fixing

[35] , reliability quality, software development and testing resources, software release timing, etc. are closely related to a(t).

[0005] In the collected literature, especially in the field of SRGM analysis, although many a(t) models are proposed in the establishment of SRGM, the focus is completely on the establishment and evaluation of SRGM, and there is little involvement in a(t) itself and its impact on the model. The biggest difficulty at present is that although many mathematical models of the total number of faults in software have been proposed, the specific value is not known in real software testing (the existing release failure data set does not contain this item), so it is difficult to directly verify.

[0006] Through the above analysis, the problems and defects of the prior art are:

[0007] (1) In reliability analysis, the total number of software failures is of great significance to test resource allocation, the impact of reliability changes, and optimal release. However, to date, there has been little reliability analysis from the perspective of the total number of failures. For issues such as imperfect troubleshooting in real-world testing environments, in-depth analysis and systematic review of the reliability growth model related to the total number of software failures are crucial. Furthermore, the impact of the total number of software failures on reliability changes should be analyzed. However, existing technologies lack reliability analysis from the perspective of the total number of failures, resulting in low accuracy of data information for software failure detection. Summary of the Invention

[0008] To overcome the problems existing in related technologies, the present invention discloses an embodiment of a software fault count detection method, system, medium, device and application, specifically involving a software fault count detection method and system based on an imperfect troubleshooting model.

[0009] The technical solution is as follows: A software fault count detection method based on an imperfect troubleshooting model, applied to a data information processing terminal, the software fault count detection method based on the imperfect troubleshooting model includes:

[0010] S1, software failure satisfies the NHPP process;

[0011] S2, the number of faults detected within (t+Δt) is proportional to the number of faults remaining in the current software;

[0012] S3, Incomplete troubleshooting and the introduction of new faults during the software repair process;

[0013] S4. During the software troubleshooting process, new faults are introduced. The total number of faults is used as a parameter of the cumulative number of detected faults m(t). m(t) is fitted and predicted with the cumulative number of detected faults in the actual failure dataset.

[0014] S5 analyzes the relationship between the change in the total number of faults in the software and the cumulative number of faults detected or repaired, and performs a ratio analysis of the number of faults introduced within (t+Δt) to the number of faults currently detected or repaired.

[0015] In one embodiment, through steps S1-S4, the following system of equations is obtained:

[0016]

[0017] Wherein, the first differential equation is a process model for modeling fault detection and imperfect repair, b(t) is the fault detection rate at time t, which is the overall description of fault detection under the current software testing environment; p(t) represents the probability of successful exclusion (repair) of faults at time t, which is set as a function of time t, indicating that there is an imperfect phenomenon of error correction in testing; p(t) m(t) represents the cumulative number of repaired faults at time t; in the second equation, a(t) is the total number of software faults at time t, which is a dynamic function that changes with testing time t. f(t) represents a certain function of a(t), which can have multiple expressions.

[0018] In one embodiment, in the process model for modeling fault detection and imperfect repair, under the initial condition of m(0) = 0, the expression of m(t) is as follows:

[0019]

[0020] Then the current failure rate λ(t) is:

[0021]

[0022] The software reliability R(t|x) in the testing phase, that is, assuming that the last failure time of the software is x (x ≥ 0, t > 0), the software reliability in (x, x+t) is represented as:

[0023] R(t|x) = e -[m(x+t)-m(x)] ;

[0024] From x = 0, the expression of m(t) is brought into the current failure rate λ(t) formula, and the relationship between reliability R(t) and a(t) is obtained, as shown in the following formula:

[0025]

[0026] a(t) is related to the reliability R(t), and R(t) is a function of a(t); with the growth of a(t), R(t) also increases.

[0027] In one embodiment, under the initial conditions of m(0) = 0 and a(0) = a, the expression of a(t) includes:

[0028] If a(t) = c + a(1-e -αt ), under the initial condition of m(0) = 0, m(t) is obtained as follows:

[0029]

[0030] At this time, a(t) is a finite number of growth, a(t→∞) = c + a.

[0031] If a(t) = ae αt Under the initial condition of m(0) = 0, m(t) is obtained as follows:

[0032]

[0033] At this time, a(t) is infinite number growth, a(t→∞)→∞;

[0034] If a(t) = a(1 + αt), under the initial condition of m(0) = 0, m(t) is obtained as follows:

[0035]

[0036] At this time, a(t) is infinite number growth, a(t→∞)→∞;

[0037] If a(t) = a(1 + rt) 2 Under the initial condition of m(0) = 0, m(t) is obtained as follows:

[0038]

[0039] At this time, a(t) is infinite number growth, a(t→∞)→∞;

[0040] If a(t) = a + αm(t), under the initial condition of m(0) = 0, m(t) is obtained as follows:

[0041]

[0042] At this time, a(t) is infinite number growth, a(t→∞)→∞.

[0043] In one embodiment, in step S5, the correlation between the variation of the total number of faults in the software and the number of faults detected or repaired cumulatively is analyzed by using the imperfect fault removal model for the incompleteness of fault removal and the imperfect fault removal model for the introduction of new faults; the analysis of the proportion of the number of faults introduced within (t + Δt) to the number of faults currently detected or repaired is performed; the imperfect fault removal model for the incompleteness of fault removal and the imperfect fault removal model for the introduction of new faults are

[0044]

[0045] Wherein, m(t) represents the number of faults detected cumulatively within [0, t], a(t) represents the total number of faults in the software, a(t) shows a growth trend for the introduction of new faults; and the number of faults detected cumulatively within [0, t] is proportional to the number of faults remaining at present, and the proportion is the fault detection rate b(t);

[0046] In the above formula, the first equation is a process model for modeling fault detection and imperfect repair, p(t) represents the probability of successfully removing (repairing) the fault at time t; the second equation is a model for analyzing the introduction of new faults in the fault repair; the first equation and the second equation respectively describe that the change rate of a(t) is proportional to the change rate of the detected fault number, wherein β(t) represents the probability of introducing faults in the error-removal process.

[0047] When the fault repair is complete, i.e., p(t) = 1, the imperfect error-removal model for the incompleteness of error-removal and the introduction of new faults evolves into a complete repair and new fault introduction model; when 0 < p(t) < 1, the imperfect error-removal model for the incompleteness of error-removal and the introduction of new faults evolves into an incomplete repair and new fault introduction model; when p(t) = 1 and β(t) = 0, or without considering the second equation, the imperfect error-removal model for the incompleteness of error-removal and the introduction of new faults evolves into a classic G-O model.

[0048] In one embodiment, let p(t) = p; The boundary conditions of the formula are: m(t) = 0 and a(t) = a;

[0049] The key fault number m(t) and the total fault number a(t) in the software are obtained by differential solution:

[0050]

[0051]

[0052] The above formula is determined by the fault detection rate b(t), the fault repair probability p(t), and the fault introduction rate β(t) variable functions, which are set according to actual conditions.

[0053] Another object of the present application is to provide a software fault number detection system based on an imperfect error-removal model, comprising:

[0054] A software failure judgment module for judging that the software failure satisfies the NHPP process;

[0055] A fault number and current software remaining fault number proportion analysis module for analyzing that the detected fault number within (t + Δt) is proportional to the current software remaining fault number;

[0056] An error-removal incompleteness and new fault introduction module for existing error-removal incompleteness and new fault introduction in the software repair process;

[0057] A new fault is introduced into the analysis module, which is used to analyze the process of software debugging, and the new fault is introduced, the total number of faults is taken as a parameter of the cumulative detected fault number m(t), and m(t) is fitted and predicted with the cumulative detected fault number in the real failure data set;

[0058] The fault number analysis module is used for analyzing the correlation between the total number of faults in the software and the cumulative detected or repaired fault number within (t+Δt) to analyze the proportion of the introduced fault number and the current detected or repaired fault number.

[0059] Another object of the present application is to provide a receiving user input program storage medium, and the stored computer program enables the electronic device to execute the software fault number detection method based on the imperfect debugging model.

[0060] Another object of the present application is to provide a computer device, which comprises a memory and a processor, and the memory stores a computer program, and the computer program is executed by the processor to enable the processor to execute the software fault number detection method based on the imperfect debugging model.

[0061] Another object of the present application is to provide an application of the software fault number detection method based on the imperfect debugging model in large and complex software, industrial software, numerical calculation and simulation software, safety software, operating system and database basic software fault detection.

[0062] In combination with all the above technical solutions, the present application has the following advantages and positive effects:

[0063] First, in view of the technical problems existing in the prior art and the difficulty in solving the problems, the technical solutions of the present application are closely combined with the results and data in the research and development process, and the technical problems are solved in detail and profoundly, and some creative technical effects are brought after the problems are solved. The specific description is as follows:

[0064] The present application comprehensively analyzes the total number of faults in the software, and systematically distinguishes different types thereof, and deeply describes the basic functions, function models and effects, which is the first time to analyze this in the field of software reliability analysis;

[0065] For the first time, a unified imperfect debugging framework model is established from the perspective of the total number of faults in the software, and a software reliability growth model covering various forms of total fault number change rate is formed;

[0066] The application evaluates the modeling and verification of the total number of faults in software by comprehensive experiments on real failure data sets in multiple practical application scenarios, analyzes the disturbance influence of the total number of faults in software on reliability models based on fitting metrics and prediction analysis, and provides important reference for in-depth analysis of differences between different models and selection of models.

[0067] The verification method of the application takes the total number of faults as a parameter of the cumulative detected faults m(t) in the established software fault detection or repair model, compares m(t) with the cumulative detected faults in the real failure data set (fitting and prediction), and indirectly indicates the accuracy of the total number of faults.

[0068] Based on a large number of previous analyses, the application mainly focuses on the influence of a(t) on the SRGM model, analyzes the modeling and evaluation of a(t) in detail, observes the changes in reliability caused by different a(t) through the establishment of a unified imperfect debugging model, and further measures the performance differences of various a(t). At the same time, the application has the disturbance influence of different forms of a(t) with the ability to describe the introduction of new faults on the SRGM model.

[0069] Secondly, from the perspective of the product or as a whole, the technical effects and advantages of the technical solution to be protected by the application are described as follows:

[0070] The application first reviews the software reliability growth model (SRGM), gives the analysis theme, essence and technical connotation, and introduces the analysis of the total number of faults in software. From the perspective of imperfect debugging and introduction of new faults, a unified binary first-order imperfect debugging differential equation set is established to describe the software testing process, and the corresponding expressions of the total number of faults and the cumulative detected faults are obtained. The imperfect debugging models in the above two categories are verified on multiple real computer engineering system failure data sets, the performance of different models is analyzed from the fitting and prediction angles, and the influence of the total number of faults in software on reliability is analyzed. The results show that the total number of faults has a significant influence on the reliability model, and its own performance can support the growth and performance improvement of reliability. BRIEF DESCRIPTION OF DRAWINGS

[0071] The accompanying drawings, which are incorporated into and form part of the specification, illustrate embodiments consistent with the present disclosure and, together with the specification, serve to explain the principles of the present disclosure.

[0072] Figure 1 is a flow chart of a software fault number detection method based on an imperfect error correction model provided by an embodiment of the present application;

[0073] Fig. 2(a) is a fitting curve on DS1 provided by an embodiment of the present application;

[0074] Fig. 2(b) is a fitting curve on DS2 provided by an embodiment of the present application;

[0075] Fig. 2(c) is a fitting curve on DS3 provided by an embodiment of the present application;

[0076] Fig. 2(d) is a fitting curve on DS4 provided by an embodiment of the present application;

[0077] Fig. 2(e) is a fitting curve on DS5 provided by an embodiment of the present application;

[0078] Fig. 2(f) is a fitting curve on DS6 provided by an embodiment of the present application;

[0079] Fig. 2(g) is a fitting curve on DS7 provided by an embodiment of the present application;

[0080] Fig. 2(h) is a fitting curve on DS8 provided by an embodiment of the present application;

[0081] Fig. 2(i) is a fitting curve on DS9 provided by an embodiment of the present application;

[0082] Fig. 2(j) is a fitting curve on DS 10 provided by an embodiment of the present application;

[0083] Fig. 2(k) is a fitting curve on DS 11 provided by an embodiment of the present application;

[0084] Fig. 2(l) is a fitting curve on DS 12 provided by an embodiment of the present application;

[0085] Fig. 3(a) is a prediction curve on DS1 provided by an embodiment of the present application;

[0086] Fig. 3(b) is a prediction curve on DS2 provided by an embodiment of the present application;

[0087] Fig. 3(c) is a prediction curve on DS3 provided by an embodiment of the present application;

[0088] Fig. 3(d) is a prediction curve on DS4 provided by an embodiment of the present application;

[0089] Fig. 3(e) is a prediction curve on DS5 provided by an embodiment of the present application;

[0090] Fig. 3(f) is a prediction curve on DS6 provided by an embodiment of the present application;

[0091] Figure 3(g) is a predicted curve on DS7 according to an embodiment of the present application;

[0092] Figure 3(h) is a predicted curve on DS8 according to an embodiment of the present application;

[0093] Figure 3(i) is a predicted curve on DS9 according to an embodiment of the present application;

[0094] Figure 3(j) is a predicted curve on DS 10 according to an embodiment of the present application;

[0095] Figure 3(k) is a predicted curve on DS 11 according to an embodiment of the present application;

[0096] Figure 3(l) is a predicted curve on DS 12 according to an embodiment of the present application;

[0097] Figure 4(a) is a curve of a(t) on DS2 according to an embodiment of the present application;

[0098] Figure 4(b) is a curve of a(t) on DS3 according to an embodiment of the present application;

[0099] Figure 4(c) is a curve of a(t) on DS4 according to an embodiment of the present application;

[0100] Figure 4(d) is a curve of a(t) on DS5 according to an embodiment of the present application;

[0101] Figure 4(e) is a curve of a(t) on DS7 according to an embodiment of the present application;

[0102] Figure 4(f) is a curve of a(t) on DS8 according to an embodiment of the present application;

[0103] Figure 4(g) is a curve of a(t) on DS9 according to an embodiment of the present application;

[0104] Figure 4(h) is a curve of a(t) on DS 11 according to an embodiment of the present application;

[0105] Figure 4(i) is a curve of a(t) on DS 12 according to an embodiment of the present application. DETAILED DESCRIPTION

[0106] In order to make the above objectives, characteristics and advantages of the present application more obvious and comprehensible, the specific embodiments of the present application are described in detail below with reference to the drawings. In the following description, a large number of specific details are set forth in order to facilitate a full understanding of the present application. However, the present application can be implemented in many other ways different from those described herein, and those skilled in the art can make similar improvements without departing from the spirit of the present application, so the present application is not limited to the specific implementations disclosed below.

[0107] I. Explanation of Embodiments

[0108] As shown in the figure, the embodiment of the present application provides a software fault number detection method based on an imperfect debugging model, applied to a data information processing terminal, which comprises: Figure 1

[0109] S101, judging that the software failure satisfies the NHPP process;

[0110] S102, analyzing that the number of faults detected within (t+Δt) is proportional to the number of remaining faults in the current software;

[0111] S103, there is an imperfection of debugging and introduction of new faults in the software repair process;

[0112] S104, in the process of software debugging, new faults are introduced, taking the total number of faults as a parameter of the cumulative number of detected faults m(t), fitting and predicting m(t) and the cumulative number of detected faults in the real failure data set;

[0113] S105, for the correlation between the change of the total number of faults in the software and the cumulative number of detected faults or the number of repaired faults, analyzing the number of introduced faults within (t+Δt) and the current number of detected or repaired faults.

[0114] The embodiment of the present application also provides a software fault number detection system based on an imperfect debugging model, which comprises:

[0115] A software failure judgment module for judging that the software failure satisfies the NHPP process;

[0116] A fault number and current software remaining fault number proportion analysis module for analyzing that the number of faults detected within (t+Δt) is proportional to the number of remaining faults in the current software;

[0117] An imperfection of debugging and introduction of new faults module for analyzing that there is an imperfection of debugging and introduction of new faults in the software repair process;

[0118] ​A new fault is introduced into the analysis module, which is used to analyze the process of software debugging, and the total number of faults is taken as a parameter of the cumulative detected fault number m(t), and m(t) is fitted and predicted with the cumulative detected fault number in the real failure data set;

[0119] The fault number analysis module is used to analyze the correlation between the total number of faults in the software and the cumulative detected or repaired fault number within (t+Δt) for the introduced fault number and the current detected or repaired fault number ratio.

[0120] In the above embodiments, the description of each embodiment has its own focus, and the parts not described or recorded in a certain embodiment can be referred to the related description of other embodiments.

[0121] The information interaction and execution process between the above devices / units are based on the same concept as the method embodiments of the present application, and the specific functions and technical effects brought by them can be referred to the method embodiment part, which will not be described here.

[0122] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the above division of functional units and modules is taken as an example, and in actual application, the above functions can be completed by different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above. Each functional unit and module in the embodiment can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or software. In addition, the specific names of each functional unit and module are only for easy distinction, and do not limit the protection scope of the present application. The specific working process of the units and modules in the system can be referred to the corresponding process in the foregoing method embodiments, which will not be described here.

[0123] In order to facilitate the understanding of the improved technical solutions of the present application, the following will be further described in combination with the knowledge related to the technical solutions of the present application, the previous achievements and the improvement of the present application.

[0124] 1. SRGM analysis content and technical analysis

[0125] Since 1978, SRGM of the non-homogeneous poisson process (NHPP) type has been the mainstream of analysis, mainly including the exponential type represented by the G-O model

[37] and its improvement and the S type model represented by the Yamada model

[38] , are all modeling the process of fault detection and repair, and then obtaining the cumulative number of detected faults (i.e. m(t) function) that can represent the software reliability. From the perspective of the number of detected and repaired faults, the growth of reliability is the starting point of SRGM analysis. Obviously, the detected faults are continuously excluded, and the reliability will inevitably be improved.

[0126] Researchers obtain the cumulative number of detected faults in [0, t] (here marked as m(t)) by modeling the testing process and verifying it with real failure data sets. In modeling, the expression of the total number of faults a(t) in the software and the fault detection rate (here marked as b(t)) are usually set by the researchers themselves. It should be noted that the differences in assumptions are the fundamental reason for the differences between different SRGMs, which leads to significant differences in the final solution of m(t). The application of SRGM for reliability analysis is the main means of modeling and evaluating reliability. Based on the extensive work of the inventors in the early stage, the SRGM modeling based on the understanding of the testing process involves the testing process, analysis content, utility of SRGM, and the corresponding relationship between the related software reliability analysis and the technology.

[0127] Currently, the analysis field closely related to SRGM as a whole presents the following technical evolution route: traditional analytical methods based on differential equations (group) modeling the fault detection and repair process in the testing process (including queue-based analysis), simulation-based analysis methods (typical such as discrete event simulation), and optimization techniques.

[0128] The analysis of SRGM basically presents the following development trend, which roughly includes six aspects of analysis topics, and the specific techniques adopted are also different. Overall, the SRGM analysis topics can be summarized into four levels, namely the analysis of SRGM itself about model establishment to evaluate reliability, the analysis of cost control based on testing resource allocation to determine the optimal release, the analysis of simulation techniques for testing process simulation, and the analysis of decision selection of numerous models.

[0129] Software reliability analysis involves various practical factors and has complex random process characteristics, covering the entire testing process, including at least the analysis content and technology as shown in Table 1, which is an important practice of combining theoretical analysis with reliability engineering and software engineering.

[0130] In the modeling of SRGM, considering the differences in the understanding of the testing process and assumptions, a large number of models have been derived, and these models all contain the key variable of the total number of faults a(t), which has become a basic consensus in the field of reliability analysis. For example, in the early G-O model, the software reliability model is established as follows:

[0131]

[0132] The model considers that the number of cumulative detected faults in the time [0, t] is m(t), and assumes that the total number of internal faults when the software starts testing is a constant, and assumes that the number of detected faults at time t (in fact, the fault change rate at time t) is proportional to the remaining number of faults in the current software (i.e. a-m(t)) (the proportional coefficient is b), so that formula (1) can be obtained, under the initial condition of m(0)=0, and then m(t)=a(1-e -bt ) is obtained by solving. In addition, the reliability R(t|x) of the software in the testing stage can be expressed as

[0133] R(t|x)=e -(m(x+t)-m(x)) (2)

[0134] Here, x is the time of the last failure of the software, for simplicity, x is set to start timing from 0, and the result of solving formula (1) is brought into formula (2), so that the reliability of the software in (0, t] can be obtained:

[0135]

[0136] Therefore, the total number of faults is not only an essential element in reliability modeling, but also determines the growth of reliability, and is the core support for modeling and measuring reliability.

[0137] It is particularly pointed out that the software reliability analysis complies with the following default rules.

[0138] (1) The implicit basis of SRGM analysis is to face large-scale software systems;

[0139] (2) In a large number of failure data sets FDS (Failure Data Set) collected in the early stage of the present application, all come from the failure data published in the testing process of large-scale software developed by well-known companies or institutions.

[0140] 2. Review of total number of faults in software

[0141] In the testing stage, with the continuous rise of the size and complexity of the software, the total number of faults in the software is an important aspect that testing personnel pay attention to. In the currently available SRGM analysis literature, the total number of faults in the software and the fault detection rate FDR (usually represented by b(t)) are both essential parameters participating in model establishment, and are important elements supporting reliability analysis. In the analysis of SRGM, the total number of faults a(t) in the software is an essential parameter, and the change of the total number of faults a(t) can describe the introduction of new faults in debugging:

[0142] ① If a(t) = a constant, it indicates that no new fault is introduced in the debugging process. This case is not consistent with the real test process, but it can simplify the complexity of problem analysis and has guiding significance for analyzing the growth trend of software reliability;

[0143] ② If a(t) = f(t), it is an increasing function of test time t. This case takes into account the possibility of introducing new faults by programmers in software repair, making the established test model more accurate, but sometimes the complexity of f(t) makes the model solution difficult.

[0144] Through analysis of a large number of documents, the facts about a(t) include the following aspects:

[0145] ① It is believed that a(t) = a, which is a constant;

[0146] ② Set a(t) as a function that increases with test time t or m(t) or W(t);

[0147] ③ a(t) > m(t), [a(t) - m(t)] represents the total number of remaining faults in the software.

[0148] It is known that in the actual test process, due to the introduction of new faults, the total number of software faults should increase with the test and modification. Therefore, setting a(t) = a is not reasonable, but in many cases, it can simplify the complexity of problem analysis, and overall, clear trend conclusions can be obtained.

[0149] Compared with m(t), which can be verified by the number of detected faults (which can be represented as n(t)) disclosed in the failure data set, a(t) is difficult to verify directly, which is the biggest obstacle to analyzing a(t) and one of the biggest deficiencies in current analysis.

[0150] Software testers and debuggers hope to eliminate all faults and achieve high reliability, but this is not easy and unrealistic.

[0151] First of all, the total number of software faults is unknown (although it can be assumed to be finite or infinite), which cannot be determined at all;

[0152] The total number of faults will increase due to the incompleteness of debugging and the introduction of new faults in the software debugging process.

[0153] Therefore, it is common to set a(t) as a certain increasing function of t, and on the basis of previous analysis, it is classified into five types in Table 1.

[0154] Table 1 Analysis of the total number of faults a(t) in software

[0155]

[0156] It can be seen that in these analyses, it is mainly considered that a(t) is in some proportional relationship with the test time or the number of detected faults m(t):

[0157] ① Although a(t) is sometimes set to a so that the a(t) obtained by modeling has better performance, new faults are introduced into the software in the actual fault repair process, so it is unreasonable to set a(t) as a constant;

[0158] ② Thus, some analyses set a(t) as an expression of t, and the present application considers that this does not essentially reflect the change of a(t) and does not clarify the problem of the close relationship between a(t) and a specific variable;

[0159] ③ Obviously, m(t) is only the fault detected at the current t time, which is only a part of a(t), so they should have a relatively close relationship, so some analyses set a(t) = a + am(t) or It has certain rationality;

[0160] ④ In addition, considering that the introduction of new faults occurs in the process of software repair, a(t) has a relatively close relationship with the current cumulative repaired fault number r(t). It is easy to know that r(t)≤m(t)≤a(t). Therefore, it is also reasonable to model a(t) from the perspective of r(t).

[0161] For the basic shape of a(t) in Table 1, where a = 50, a = 0.25, b = 0.35, r = 0.25, t ∈ [0, 20], (m(t) adopts the classic G-O model (i.e. m(t) = a[1-e -bt ])).

[0162] The basic shape of m(t) corresponding to the three types of a(t) in Table 1, where a = 50, a = 0.25, b = 0.35, c = 20, p = 1, r = 0.25, t ∈ [0, 20].

[0163] It can be seen that the curve growth shape of a(t) can be roughly divided into three types: convex exponential growth, concave exponential growth and linear growth; at the same time, under the condition that the fault detection rate b(t) and the fault repair probability p(t) are fixed as constants, a(t) and m(t) are relatively similar in curve form, that is, the concave-convexity and the increase-decrease of the image are roughly consistent.

[0164] In the effective test environment, m(t) grows and is closer to a(t) (m(t)≤a(t)), so there is a strong similarity between the two curves. Most SRGM models show exponential growth, which is consistent with the literature that most SRGMs belong to exponential growth trend.

[0165] 3. The modeling of software total fault related imperfect debugging model and performance influence evaluation

[0166] 3.1 The modeling of software total fault related imperfect debugging model

[0167] Compared with the prior art perfect debugging model, the real software testing process is a complex process influenced by various random factors, typically, the incompleteness of debugging and the introduction of new faults are two real existing phenomena, which are the real imperfect debugging process. The incompleteness of debugging is an imperfect debugging, and the introduction of new faults in debugging is also an imperfect debugging, and here the imperfect debugging mainly focuses on the incompleteness of debugging or the introduction of new faults. Therefore, the present application will establish the software total fault related SRGM from the perspective of imperfect debugging, and analyze the influence of total fault on SRGM.

[0168] Firstly, based on the public assumptions established by SRGM, the content related to imperfect debugging is added to form the following assumptions:

[0169] ① The software failure satisfies the NHPP process;

[0170] ② The number of faults detected in (t+Δt) is proportional to the number of remaining faults in the current software;

[0171] ③ There are the phenomena of the incompleteness of debugging and the introduction of new faults in the software repair process.

[0172] 3.1.1 The first imperfect debugging model case-directly setting the total fault number expression

[0173] In the first case, the analyst directly sets the total fault number to a certain function form to model the growth of the total fault number in testing, and for this purpose, the present application adds the following assumptions:

[0174] ④ In the process of software debugging, there is the phenomenon of new faults being introduced, and the total number of faults in the software is a certain increasing function of the test time t.

[0175] On the basis of assumptions ① to ④, the equation group as shown in equation (4) can be obtained:

[0176]

[0177] The first differential equation models the process model of fault detection and imperfect repair, b(t) is the fault detection rate at time t, which is the overall description of fault detection at the current time in the software testing environment; p(t) represents the probability of successful exclusion (repair) of faults at time t, which can be set as a function of time t, indicating the incomplete phenomenon of error correction in testing; p(t) m(t) represents the cumulative number of repaired faults at time t; a(t) in the second equation is the total number of software faults at time t, which is a dynamic function that changes with testing time t.

[0178] In formula (4), when only the first sub-formula is considered, under the initial condition of m(0) = 0, the expression of m(t) can be obtained as follows:

[0179]

[0180] Then the current failure rate λ(t) is:

[0181]

[0182] The software reliability R(t|x) in the testing phase, that is, assuming that the last failure time of the software is x (x ≥ 0, t > 0), the software reliability in (x, x+t) can be expressed as:

[0183] R(t|x) = e -[m(x+t)-m(x)] (7)

[0184] If it is assumed that x = 0, formula (5) is brought into formula (6), then the relationship between reliability R(t) and a(t) can be obtained, as shown in the following formula:

[0185]

[0186] It can be seen that a(t) is closely related to the reliability R(t), and R(t) is a function of a(t). With the growth and change of a(t), R(t) also increases. Therefore, analyzing a(t) can be an important method to master R(t) and optimal release.

[0187] a(t) is mainly set as the following five forms, under the initial conditions of m(0) = 0 and a(0) = a, the expression of a(t) can be obtained as shown in the following five cases:

[0188] If a(t) = c + a(1-e -αt ), under the initial condition of m(0) = 0, then m(t) can be obtained as follows:

[0189]

[0190] At this time, a(t) is a finite number of growth, a(t→∞) = c + a.

[0191] If a(t) = ae αt Under the initial condition of m(0) = 0, m(t) can be obtained as follows:

[0192]

[0193] At this time, a(t) is infinite number growth, a(t→∞)→∞.

[0194] If a(t) = a(1 + αt), under the initial condition of m(0) = 0, m(t) can be obtained as follows:

[0195]

[0196] At this time, a(t) is infinite number growth, a(t→∞)→∞.

[0197] If a(t) = a(1 + rt) 2 Under the initial condition of m(0) = 0, m(t) can be obtained as follows:

[0198]

[0199] At this time, a(t) is infinite number growth, a(t→∞)→∞.

[0200] If a(t) = a + αm(t), under the initial condition of m(0) = 0, m(t) can be obtained as follows:

[0201]

[0202] At this time, a(t) is infinite number growth, a(t→∞)→∞.

[0203] 3.1.2 The second imperfect error model case - setting the change rate of the total number of faults from the differential equation

[0204] In the second case, it is considered that the change of the total number of faults in the software is related to the cumulative detected faults or the repaired faults, therefore, the present application adds the following assumptions to the first case:

[0205] (5) The number of faults introduced in (t + Δt) is proportional to the current detected or repaired faults.

[0206] On the other hand, it can be known that the new fault introduction is occurred in the process of fault repair due to the programmer's change to the program structure, compared with the proportionality of a(t) change rate and the detected fault number change rate, the proportionality of a(t) change rate and the repaired fault number change rate is closer to the real test process, therefore, the present application proposes the following consideration of the imperfection of bug fixing and the imperfect bug fixing model of new fault introduction:

[0207]

[0208] Wherein, m(t) represents the cumulative detected fault number in [0, t], a(t) represents the total fault number in the software, since the new fault introduction is considered, a(t) shows the increasing trend. The differential equation establishes the assumption basis: the cumulative detected fault number in [0, t] is proportional to the current remaining fault number, the proportion is the fault detection rate b(t). The first sub-formula models and depicts the fault detection and repair model, p(t) represents the probability that the fault at t time is successfully excluded (repaired). The second sub-formula models and describes the model of new fault introduction in the fault repair, respectively describes the proportionality of a(t) change rate and the detected fault number change rate, wherein β(t) represents the fault introduction probability in the bug fixing process.

[0209] Obviously, when considering that the fault repair is complete, that is, p(t) = 1, formula (9) evolves into the complete repair and new fault introduction model; when 0 < p(t) < 1, formula (14) evolves into the imperfect repair and new fault introduction model; when p(t) = 1 and β(t) = 0, or without considering the second sub-formula, formula (14) evolves into the classical G-O model.

[0210] The above formula is relatively complex in solving, in order to reduce the complexity, considering the convenience and feasibility of solving and not affecting the overall efficiency of the model, it is not difficult to make p(t) = p. The boundary condition of the above formula is: m(t) = 0 and a(t) = a.

[0211] Let

[0212] x(t) = a(t) - p·m(t) (15)

[0213] Taking the differential of both sides to get

[0214]

[0215] Substituting the second sub-formula in (14) into (16) can obtain

[0216]

[0217] Substituting the first sub-formula in (14) into (17) can obtain

[0218]

[0219] Substitute (15) into (18), we have

[0220]

[0221] From the initial condition, we have x(0) = a(0) - p - m(0) = a. Then, from the general solution of the first order homogeneous linear differential equation, we have the solution of (19) as

[0222]

[0223] Substitute (15) into the first sub-expression of (14), we have

[0224]

[0225] Substitute (20) into (21), we have

[0226]

[0227] Substitute (22) into the second sub-expression of (14), we have

[0228]

[0229] In this case, the expressions of the number of critical faults m(t) and a(t) are solved, and are determined by three parametric functions, i.e. the fault detection rate b(t), the fault repair probability p(t), and the fault introduction rate β(t). These parametric functions can be set according to the actual situation, which provides support for the framework, unity and flexibility of the model. This provides a more objective basis for the information of a(t) and other information concerned by SRGM, and more directly reflects the changes of actual factors.

[0230] 3.1.3 Theoretical verification

[0231] 1) Two cases about a(t)

[0232] In the first case, a(t) is directly set by the analyst as a certain expression of function, or increases with the test time t, or increases exponentially, or increases with m(t). These types model the growth of a(t) from different angles, and are generally consistent with people's understanding of the test process, and have a certain effectiveness.

[0233] Compared with the expression of a(t) directly set, in the second case, the growth rate of a(t) and the close relationship between the cumulative number of detected and repaired faults in software testing are given, which more objectively describes the internal nature of fault detection and removal in testing. da(t) / dt is proportional to dm(t) / dt, indicating that as faults are continuously detected, new faults are continuously introduced; da(t) / dt is proportional to d[p(t)·m(t)] / dt, indicating that new faults are continuously introduced in the process of fault repair. It is easy to know that the introduction of new faults occurs in the process of fault repair, so the latter is more in line with the real testing process.

[0234] In the two cases, a(t) = a + αm(t) is directly set, and a(t) = a + αm(t) is set They are equivalent, but due to different parameters, there will be slight differences in the specific model performance evaluation (fitting and prediction).

[0235] 2) Effectiveness of the verification method

[0236] Regarding the proposed model verification, since the total software failure information has not been released in the current failure data set, it cannot be directly verified, but only the cumulative number of detected faults in the failure data set can be verified by the m(t) obtained by modeling. Obviously, this verification is indirect.

[0237] Since the G-O model was proposed in 1978, hundreds of SRGMs have been proposed, and the above assumption ① is included in their assumptions, and differential equations of various forms have been established based on this. The differential equation established in the present application covers various forms of current analysis and is a framework model:

[0238]

[0239] The differential equation models the fault detection (and repair) process in the testing process

[0240] b(t) is the fault detection rate function, the value is between (0, 1); p(t) is the fault repair probability, the value is between (0, 1). a(t) can be a constant, or a certain increasing function of t, or it can be set by its growth rate da(t) / dt. It can be seen that b(t), p(t) and a(t) can be set according to needs, and various existing models can be obtained.

[0241] The six forms of the above two cases of a(t) are certain recognitions about a(t) in the current analysis of the test process, and thus to some extent depict the change of the total number of faults in the test process. In the above framework model, the obtained m(t) and a(t) have typicality and practicability by combining various a(t) models, which can become a perspective for verifying the effectiveness of a(t). Therefore, the model established here has typicality and reasonableness.

[0242] 4. Performance evaluation of the model

[0243] 4.1 Model selection

[0244] The model obtained above is verified by experiments on real failure data sets to analyze the influence of a(t) on the model. These data sets are all from real engineering and published by different companies.

[0245] The fault detection rate FDR: b(t) is used to describe the degree of fault detection in the current test environment, and the fault repair probability p(t) represents the probability of fault repair in the current repair environment. Both of them are closely related to the overall test strategy (technology, tool, test personnel skill, etc.), repair strategy, etc. There can be multiple function forms. Here, we mainly focus on the influence of a(t) on the model, without loss of generality, we can set b(t) = b constant, p(t) = p constant. Imperfect debugging is to continuously relax the conditions assumed in traditional perfect debugging, so that the actual factors considered are closer and closer to the real situation. Since imperfect debugging more realistically describes the actual test process, this invention selects six typical imperfect debugging related SRGMs (as shown in Table 2) on 12 data sets (DS1-DS6, DS7, DS8-DS9[DS 10 —DS 12 ) to verify, and analyze the essential differences of different models under different total fault types.

[0246] Table 2 Typical imperfect debugging related SRGMs under the perspective of a(t)

[0247]

[0248] Without loss of generality, in the experiment, the fault detection rate b(t) in equations (6)-(10) is set to a constant b, and the fault removal rate p(t) is set to a constant p, and the performance of different total fault quantities a(t) in the framework model is focused on. The cumulative fault detection quantity function expression corresponding to the framework model with constant is shown in Table 3.

[0249] Table 3 Software total fault quantity function a(t) in the framework model

[0250]

[0251] The SRGM related to the above imperfect debugging is experimented on multiple published real computer engineering system failure data sets, the performance of different models is observed, and comparison is made. On the other hand, the relationship and influence of the failure data set and the SRGM are analyzed from the fitting and prediction angles, and the parameter functions in the SRGM are analyzed, covering the influence between the following: And Finally, the deficiencies of the current failure data set are analyzed from the perspective of the publisher and the scientific researcher, and suggestions for the optimal release of software and the release of the failure data set are given, which lays the foundation for the decision analysis of the subsequent SRGM.

[0252] 4.2 Fitting performance experiment and analysis

[0253] The present application provides the cumulative detected failure quantity curves of 12 published failure data sets and the estimated value curves of the SRGM models participating in comparison, the models participating in comparative analysis are DS1~DS 12 The fitting curve graphs are shown in Figures 2(a)-2(l) . Among them, the closer the fitting curve of the model to the real failure data curve indicates the better the fitting effect.

[0254] Figures 2(a)-2(l) In the figures, the cross curve is Y-Lin; the star curve is P-N-Z-Model; the black dot curve is P-Z-Model; the oblique cross curve is P-Z; the rectangular curve is Pham; the diamond curve is Ohba-Chou; the upward triangle curve is M-7; the downward triangle curve is M-8; the right triangle curve is M-9; the left triangle curve is M-10; the five-star curve is M-11; and the six-star curve is M-112.

[0255] By comparing the fitting curves corresponding to the existing models (Y-Lin~Ohba-Chou) and the framework models (M-7~M-11 and M-12) proposed in the present application, the rationality of the framework models of the present application can be verified. In addition, since the models M-7~M-11 are derived by fixing the fault detection rate b(t)=b and the fault removal rate p(t)=p in the unified framework model and bringing in different software total fault quantity functions, the performance of a(t) can be estimated by analyzing the performance of the models M-7~M-11 on various data sets. From the experimental fitting curve results on different data sets, it can be seen that:

[0256] (1) Overall, except that the fitting curve of M-3 deviates from the failure data set curve seriously on DS8 and DS12, the fitting results of other models are consistent with the failure data set. This shows that the two framework models based on NHPP assumption proposed in the application, i.e., directly setting the total failure function and differentiating the total failure function, are feasible, and can estimate the number of faults detected in the software testing process after bringing in different forms of total failure function a(t) and fault detection rate function b(t).

[0257] (2) In detail, the fitting curve of M-2 is closest to the failure data set curve on DS 2～3 , DS 5～8 and DS 11～12 , and has the best fitting performance. The reason is that on the one hand, the M-2 model adopts a linearly increasing total failure number function, and on the other hand, the fault detection rate b(t) of the model is set to a more flexible S-shaped form b(t) = b / (1 + βe -bt ). This shows that in addition to the software total failure number function, different forms of fault detection rate function b(t) will also have an important impact on the performance of the SRGM model. In the framework model M7-M-11 with fixed fault detection rate function, the fitting performance of the M-7 model corresponding to the optimistic type of total failure number function is the best, and the estimated curve of the model is closest to the failure data set curve on DS 1、3、6、4、7、9、12 . This shows that on the above data sets, the optimistic type of total failure number with an upper limit can better describe the trend of the total failure number in the software testing process. The models M-8-M-10 corresponding to the pessimistic type of software total failure number show relatively consistent results, and have excellent fitting performance on specific data sets (for example, DS5 and DS 10 ), but perform poorly on most data sets. Among them, the M-9 model corresponding to the pessimistic type of linearly increasing total failure function has better fitting performance on DS 12 , and its performance is better than that of the other two models corresponding to the pessimistic type. The models corresponding to the a(t) of the compromise type and the indirect solving type have similar performance, and the fitting curves on most data sets are relatively close to the true data set curve.

[0258] (3) In the S-shaped growth model of DS3, only M-2 and M-3, which consider the S-shaped b(t), can better fit the actual test situation of the failure detection rate in the software testing cycle, which is from low to high and then gradually decreases after reaching a peak. The fitting curves of other models are all straight lines and cannot accurately describe the growth trend of the failure dataset. In particular, since the failure detection rate b(t) is constant, M-7 to M-11, corresponding to the total number of failures in the optimistic, pessimistic, and compromise types, cannot fit the cumulative number of detected failures in the S-shaped growth. This phenomenon can be explained by the fact that the total number of failures function a(t), as one of the important influencing factors in the software reliability growth model, has certain limitations on the performance of the model. For the more complex S-shaped growth failure dataset, a more flexible S-shaped failure detection rate function can be used in the framework model to improve the model performance.

[0259] (4) Among the 12 SRGM models compared in this invention, no single model performed well on all datasets. For example, M-2 performed well on 8 datasets, but not on DS. 10 With DS 12 The fitting curves on these two datasets performed poorly. The reason for this is that different software systems have different architectures, and different software testing environments also vary significantly; these differences ultimately manifest in the failure datasets. Furthermore, the software reliability growth model is based on abstract assumptions and uses certain mathematical methods to estimate the cumulative number of detected failures, which inevitably cannot cover all the complex failure datasets.

[0260] 4.3 Predictive Performance Experiments and Analysis

[0261] To observe the predictive performance of the models, this invention plotted the prediction RE curves of the models participating in the comparison analysis. The models participating in the comparative analysis were plotted in the range of DS1 to DS2. 12 In the prediction curve, such as Figures 3(a)-3(l) As shown, the closer the RE curve is to 0, the better the predictive performance. A curve above 0 indicates a positive prediction, while a curve below 0 indicates a negative prediction. Predictions based on the dataset can be seen as the model's ability to describe future test performance, and also reflect the accuracy with which the model accumulates and detects faults in subsequent time steps.

[0262] Figures 3(a)-3(l) In the diagram, the crosshair curve is Y-Lin; the asterisk curve is PNZ-Model; the black dot curve is PZ-Model; the diagonal cross curve is PZ; the rectangle curve is Pham; the diamond curve is Ohba-Chou; the upward triangle curve is M-7; the downward triangle curve is M-8; the right triangle curve is M-9; the left triangle curve is M-10; the five-pointed star curve is M-11; and the six-pointed star curve is M-112.

[0263] Analyzing the prediction curves of the above models, we can see that:

[0264] (1) Overall, except that the fitting curve of M-2 has a large deviation and does not converge to the zero level line on some data sets, most models show good prediction performance. And the more software failure-related data collected, the better the prediction performance of the model as the test time increases.

[0265] (2) The prediction performance of the model has a certain correlation with the fitting performance. The prediction curve of the model corresponding to the total number of faults function of the compromise type and the differential solution form is relatively close, and performs well on most data sets, with relatively stable prediction performance. The prediction ability of the model corresponding to a(t) of the optimistic type and the linear pessimistic type has volatility, and performs well on some data sets (such as DS5, DS 11 , etc.), but there is a certain deviation on some data sets. The prediction ability of the model corresponding to a(t) of the exponential pessimistic type and the quadratic pessimistic type is relatively unstable, and the prediction performance on some data sets is poor.

[0266] (3) For the S-shaped growth data set DS2, although the fitting curves of the framework models M-7~M-12 cannot exhibit the special trend of the S-shaped growth of the data set, the fitting performance of the model is poor, but the prediction curve of the model still tends to the zero level line in the latter part of the software test. This shows that if the software reliability growth model can basically fit the growth trend of the failure data set, the model can still predict the number of software faults well under the condition of collecting a certain amount of test data.

[0267] 4.4 Correlation analysis

[0268] Based on the experimental results of the above 12 models on 12 published failure data sets, the following in-depth discussions can be made:

[0269] (1) Because of the differences between the modeling assumptions of software reliability growth models and the real software testing process, there is no model that can well fit all failure data sets. The more realistic factors considered in the model assumptions, the better the fitting and prediction performance of the model. Compared with the total number of faults with a constant a, the reliability model corresponding to the total number of faults function a(t) that changes with test time t considering imperfect debugging has better performance.

[0270] (2) According to the comprehensive experimental results, the performance of the different types of total failure quantity functions participating in the unified framework model comparison can be preliminarily sorted: optimistic type > linear pessimistic type > quadratic pessimistic type > exponential pessimistic type > compromise type = differential solution type. The model holding a conservative assumption on the total failure quantity has better fitting performance, such as the optimistic type and the linear pessimistic type. The quadratic type and the exponential type with rapid growth of software faults with test time t have good fitting performance on individual data sets. The compromise type and the solution type have a compromise in fitting performance and stable prediction performance on most data sets.

[0271] (3) The software total failure function is a description of the total number of faults of a software system, including both detected faults and the number of faults that have not yet been found. In software reliability modeling, the total number of faults can be artificially set to the optimistic type with an upper limit of growth, the pessimistic type without an upper limit of growth, the compromise type varying with the cumulative number of detected faults, and the differential solution type. On the same data set, the models corresponding to the optimistic and pessimistic types of total failure quantity have completely opposite performance, and if the model corresponding to the optimistic type has the best performance, the model corresponding to the pessimistic type has poor performance, and vice versa. According to the definition of the software total failure function, it can be inferred that in the failure data set where the optimistic type performs well, the total number of faults of the software system corresponding to the data set has an upper limit, and the final total number of faults remains stable with the increase of test time; the data set where the pessimistic type performs well corresponds to a software system without an upper limit on the total number of faults, and the number of faults of the software system gradually increases with the increase of test time.

[0272] Based on the above analysis, most of the failure data sets participating in the experiment of the present application are optimistic types with an upper limit on the total number of software faults. However, the judgment of the total number of faults of a software system should also be made in combination with actual factors such as the skill level of software programmers, the proficiency of software testers, and the degree of software development standardization.

[0273] (4) Different types of total failure quantity functions In order to improve the performance of the software reliability growth model, in addition to considering the software total failure quantity, appropriate fault detection rate FDR, fault removal probability p(t), testing effort TE, testing coverage TC and other factors should be determined to make the modeling process closer to the real software testing situation and play the comprehensive effect of internal integration, so as to obtain a software reliability growth model with better fitting and prediction performance.

[0274] 5 Problems to be solved

[0275] 5.1 Analysis

[0276] 5.1.1 Establishing a function that can describe the total number of faults in each stage of the software life cycle

[0277] In the requirement analysis stage of software, the quality problem of "inaccurate portrait" may be caused by the lack of understanding of business logic by the requirement analyst; in the software design stage, potential faults may be caused by design defects of the designer (e.g. architect); in the software development stage, bugs may exist in the software due to the lack of development ability of the programmer; in the software testing and modification stage, the overall strategy and personnel level of the error-removal process may also introduce new errors into the software. These defects, risks, deficiencies, hidden dangers and problems will cause various faults and even failures in the long-term operation of the software, and even cause huge losses in serious cases. How to establish a total number of faults model covering the main life cycle of software, more accurately depict the generation mode of the total number of faults, and quantitatively describe the role of the stage-based total number of faults model in improving reliability is an important content to promote the high-quality development of software engineering. Limited by the progress of process modeling in each stage of the software life cycle and the analysis of theoretical models, and the imperfection of current software testing and publishing information, it is difficult to break through the establishment of a multi-stage software total number of faults model, which has become a challenge in the whole reliability analysis.

[0278] 5.1.2 Establishing a quantitative relationship between the total number of faults in software and more factors in the testing process

[0279] Software reliability is one of the main indicators of high-reliability software and plays an important role in the quality system of software. In fact, reliability is the result of the comprehensive action of multiple factors including the total number of faults, and the improvement of reliability by analyzing or taking measures from a single factor is limited. From the perspective of the total number of faults, testing strategy development, testing resource allocation, test case generation, and test path selection will all affect fault removal and testing quality. Only by establishing a quantitative relationship model of the correlation of multiple factors can we more deeply, comprehensively and accurately analyze the changes of reliability. In future reliability theory analysis, we should pay attention to the comprehensive correlation analysis of multiple factors, scientifically view the factors that restrict reliability, and reasonably establish a mathematical model that supports the continuous growth of reliability over time, thereby guiding the high-quality development of software reliability engineering.

[0280] 5.2 Problems to be solved urgently

[0281] 5.2.1 Selecting the appropriate total number of faults model in real software engineering development

[0282] From the analysis of the present application, it can be seen that the total number of faults in software has an important influence on software reliability, and the total number of faults in software function has various forms. Therefore, in the real software development, how to determine or formulate the appropriate total number of faults in software function is of great significance to guide software testing, improve reliability and timely release of software. Because different stages of software development have different characteristics, the strategy of determining the appropriate total number of faults in software function can be adopted in stages, which will be meaningful to guide the healthy development of software engineering. From the current analysis, the total number of faults in software function is still mainly set by human subjective, lacks sufficient theoretical basis, and it is still difficult to provide scientific guidance for large software project development, and this problem needs to be broken through.

[0283] 5.2.2 To establish a more accurate software release strategy based on the total number of faults

[0284] Software release is the transition of software from the development stage to the application stage, which is of great significance to determine software quality, control development and testing cost, and timely put into market or deliver to users. The total number of faults in software is an important factor to determine software release, so it is an important analysis topic to formulate a reasonable release strategy based on software fault total number model. Software release does not mean that there is no fault in software, but the fault does not affect the use of software (or the scope and degree of influence is acceptable) and is modified and iterated to improve and put into application. We have conducted in-depth analysis on software testing resource allocation, cost control and release

[85] , and found that so far, the consideration of total number of faults in software release strategy is not enough, and the influence of total number of faults on reliability is ignored, which makes the software release not accurate enough. Here, we propose an optimization decision model for software release from the perspective of total number of faults.

[0285]

[0286] Here, c(t) represents the number of cumulative repaired faults at time t, and C(T) represents the cost consumed by the end of software release T. The optimization decision model can be understood as minimizing the number of remaining faults in software under the condition of not exceeding the cost and achieving the minimum reliability. Solving the optimization mathematical model can determine the optimal release time T of software.

[0287] 5.2.3 Establishing a total number of faults model based on a more abundant failure data set

[0288] Because there is a possibility of introducing new faults in the process of testing and troubleshooting, a(t) should increase with t. For this, the present application provides the variation curves of different a(t) models on partial failure data sets, and the total failure curve estimated by the model in the partial failure data set curve, such as Figures 4(a)-4(i)In the figure, the circle curve is the failure data; the star curve is the optimistic a(t) curve; the oblique cross curve is the exponential pessimistic a(t) curve; the rectangular curve is the linear pessimistic a(t) curve; the diamond curve is the quadratic pessimistic a(t) curve; the upward triangular curve is the compromise a(t) curve; and the five-star curve is the differential solution a(t) curve.

[0289] Due to the difference in the setting of a(t), the trend of the curve is not only linearly increasing, but also exponentially and more complexly increasing. The failure data set records part of the total number of software faults, which should be similar, but observation shows that there is a large gap between them, which is due to the deviation of the assumption of a(t) by software reliability modeling personnel. Since the FDS publisher is the leader of the test process, it has the ability to obtain more accurate information of a(t), but there is no such information in the current FDS. This not only brings serious constraints to the total number of fault models, but also to the reliability analysis, which is a problem that needs to be broken through. We call on the FDS publisher (company or analysis institute) to publish more comprehensive information of the failure data set to help software reliability modeling personnel to model the total number of faults more accurately.

[0290] 5.2.4 Evolution characteristics of the total number of faults under the condition of significant changes in software structure and morphology

[0291] The development mode, technology, structure, and morphology of software will all affect the distribution and growth of faults in software. Current analysis still treats software as a form of uniformity, without distinguishing the changing characteristics of software itself, and ignoring the changes in the total number of faults caused by software development. For example, with the development of development modes (open source development, iterative development, agile development, crowd funding development, etc.), especially the improvement of requirements and application innovation, component software, web software, open source software, platform software, social and communication software, and mobile terminal software have become the mainstream of software. It is necessary to pay enough attention to the analysis of the distribution and growth of faults in these software forms and structures. Faults are often caused by problems or deficiencies in development, so it is necessary to analyze the total number of faults in combination with software architecture and development characteristics. For example, software architecture models, development paradigms, software development and testing theories and technologies should be linked to the distribution and generation of the total number of faults, and models considering more software development characteristics should be established to improve the adaptability, accuracy, and effectiveness of the analysis.

[0292] The total number of faults in software is an important element of software reliability modeling, evaluation and growth, and has an important influence on test resource allocation, cost control and optimal release. The total number of faults in software is difficult to determine and difficult to completely eliminate. In current software reliability analysis, the total number of faults is mainly set directly, which brings certain difficulties to establish more accurate reliability models and determine more accurate test resource investment. According to the characteristics of software structure and the like, a model capable of describing the growth of the number of faults in software is established, which not only brings direct benefits to determine the introduction of new faults in error elimination, but also becomes an important force to promote the development of reliability engineering, and is a core theme worthy of exploration in the field of reliability analysis.

[0293] The present application comprehensively reviews the total number of faults in software, including distinguishing different function models, and then establishing software test models of two imperfect error elimination conditions from the perspective of the total number of faults in software, and establishing a plurality of classification sub-models. In view of the obtained reliability model, the differences between the model performance are analyzed from the angles of fitting and prediction, and the influence of the total number of faults on reliability is analyzed.

[0294] II. Application Examples

[0295] The application embodiment further provides a computer device, which comprises at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, wherein the processor implements the steps in any of the above method embodiments when executing the computer program.

[0296] The application embodiment further provides a computer readable storage medium, which stores a computer program, wherein the computer program is executable by a processor to implement the steps in any of the above method embodiments.

[0297] The application embodiment further provides an information data processing terminal, which is used to provide a user input interface to implement the steps in any of the above method embodiments when executed on an electronic device, and is not limited to a mobile phone, a computer or a switch.

[0298] The application embodiment further provides a server, which is used to provide a user input interface to implement the steps in any of the above method embodiments when executed on an electronic device.

[0299] The application embodiment provides a computer program product, which, when executed on an electronic device, enables the electronic device to implement the steps in any of the above method embodiments.

[0300] The integrated unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, all or part of the processes in the above-mentioned embodiment methods can be completed by instructing related hardware through a computer program. The computer program can be stored in a computer readable storage medium. When the computer program is executed by a processor, the steps of each method embodiment described above can be implemented. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or some intermediate forms. The computer readable medium at least includes any entity or device capable of carrying the computer program code to the photographing device / terminal equipment, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunications signal, and a software distribution medium. For example, a U disk, a mobile hard disk, a magnetic disk, or an optical disk.

[0301] The above merely describes the preferred embodiments of the present application, but the protection scope of the present application is not limited thereto. Any modification, equivalent replacement, and improvement within the technical range disclosed by the present application, and within the spirit and principle of the present application, should be covered within the protection scope of the present application.

Claims

1. A method for software fault number detection based on an imperfect bug fixing model, characterized in that, The method for detecting the number of software faults based on an imperfect debugging model is applied to a data information processing terminal and comprises the following steps: S1, the software failure satisfies an NHPP process; S2, the number of faults detected within t+Δt is analyzed to be proportional to the number of remaining faults in the current software; S3, there is an imperfection in debugging and new faults are introduced during the software repair process; S4, during the software debugging process, the total number of new faults introduced is taken as a parameter of the cumulative detected fault number m(t), and m(t) is fitted and predicted with the cumulative detected fault number in the real failure data set; S5, the correlation between the total number of faults in the software and the cumulative detected or repaired fault number is analyzed, and the proportion of the number of faults introduced within t+Δt to the current detected or repaired fault number is analyzed; Through steps S1-S4, the following equation group is obtained: wherein, For modeling the process model of fault detection and imperfect repair, b(t) is the fault detection rate at time t, which is the overall description of fault detection under the current software testing environment; p(t) represents the probability of successfully excluding faults at time t, which is set as a function of time t, indicating the imperfect phenomenon of error elimination in testing; p(t)·m(t) represents the cumulative number of repaired faults at time t; a(t) = f(t) in a(t), a(t) is the total number of software faults at time t, which is a dynamic function that changes with testing time t, and p(t) represents the probability of successfully excluding faults; In step S5, the correlation between the total number of faults in the software and the cumulative detected or repaired fault number is analyzed by using the imperfect debugging model for the imperfection in debugging and the introduction of new faults, and the proportion of the number of faults introduced within t+Δt to the current detected or repaired fault number is analyzed; the imperfect debugging model for the imperfection in debugging and the introduction of new faults is as follows: Wherein, m(t) represents the cumulative detected fault number within [0, t], a(t) represents the total number of faults in the software, a(t) shows a growth trend for the introduction of new faults; and the cumulative detected fault number within [0, t] is proportional to the current remaining fault number, and the proportion is the fault detection rate b(t); In the above formula, is: the process model of fault detection and incomplete repair; p(t) represents the probability of successful elimination of faults at time t; is the model of introducing new faults in the analysis of fault repair; and is proportional to the change rate of a(t) and the change rate of the detected fault number respectively, wherein β(t) represents the probability of introducing faults in the troubleshooting process; When the fault repair is perfect, i.e. p(t) = 1, the imperfect debugging model with imperfect debugging and new-fault introduction evolves into the perfect-repair and new-fault introduction model; when 0 < p(t) < 1, the imperfect debugging model with imperfect debugging and new-fault introduction evolves into the imperfect-repair and new-fault introduction model; when p(t) = 1 and β(t) = 0, or not considering the imperfect debugging, the imperfect debugging model with imperfect debugging and new-fault introduction evolves into the classic G-O model.

2. The method of claim 1, wherein the method is based on an imperfect bug model. In the modeling of the fault detection and imperfect repair process model, the initial condition is m(0)=0, and the expression of m(t) is as follows: The current failure rate λ(t) is as follows: The software reliability R(t|x) in the test phase is as follows: the last failure time of the software is x (x≥0, t>0), and the software reliability within (x, x+t) is as follows: R(t|x) = e -[m(x+t)-m(x)] ; From x=0, the expression of m(t) is brought into the current failure rate λ(t), and the relationship between the reliability R(t) and a(t) is obtained, as shown in the following formula: a(t) is related to the reliability R(t), and R(t) is a function of a(t); with the growth and change of a(t), R(t) also increases and improves.

3. The method of claim 2, wherein the method is based on an imperfect bug model. Under the initial conditions of m(0)=0 and a(0)=a, the expression of a(t) includes: If a(t) = c + a(l - e -αt Under the initial condition m(0) = 0, m(t) is obtained as follows: At this time, a(t) is a finite number of growth, a(t→∞)=c+a; If a(t) = ae αt With the initial condition m(0) = 0, then m(t) is found as follows: At this time, a(t) is an infinite number of growth, a(t→∞)→∞; If a(t)=a(1+αt), under the initial condition of m(0)=0, m(t) is obtained as follows: At this time, a(t) is an infinite number of growth, a(t→∞)→∞; If a(t) = a(l + rt) 2 With the initial condition m(0) = 0, then m(t) is found as follows: At this time, a(t) is an infinite number of growth, a(t→∞)→∞; If a(t)=a+αm(t), under the initial condition of m(0)=0, m(t) is obtained as follows: At this time, a(t) is an infinite number of growth, a(t→∞)→∞.

4. The method of claim 1, wherein the method is based on an imperfect bug model. Let The boundary conditions for the equation of are: m(t) = 0 and a(t) = a; by differentiation, the critical number of faults m(t) and the total number of faults in the software a(t) are obtained: The above formula is determined by the fault detection rate b(t), the fault repair probability p(t) and the fault introduction rate β(t) variable functions, which are set according to actual conditions.

5. A software fault number detection system based on an imperfect debugging model, which implements the software fault number detection method based on an imperfect debugging model according to any one of claims 1 to 4, characterized by The software fault number detection system based on the imperfect debugging model is applied to a data information processing terminal and comprises: A software failure judgment module is configured to determine whether the software failure satisfies the NHPP process. A fault number and current software remaining fault number proportional analysis module is configured to analyze the proportion of the number of faults detected within t+Δt to the number of remaining faults in the current software. An imperfect debugging and new fault introduction module is configured to analyze the imperfect debugging and new fault introduction in the software repair process. A new fault introduction analysis module is configured to analyze the total number of new faults introduced in the software debugging process as a parameter of the cumulative detected fault number m(t), and fit and predict m(t) and the cumulative detected fault number in the real failure data set. A fault number analysis module is configured to analyze the proportion of the number of faults introduced within t+Δt to the number of currently detected or repaired faults in relation to the change of the total number of faults in the software and the cumulative detected or repaired fault number. 6.A receiving user input program storage medium, wherein a computer program is stored in the medium, and the computer program makes an electronic device execute the software fault number detection method based on the imperfect debugging model according to any one of claims 1 to 4.

7. A computer device, characterized by The computer device comprises a memory and a processor, and the memory stores a computer program, and the computer program makes the processor execute the software fault number detection method based on the imperfect debugging model according to any one of claims 1 to 4 when the processor executes the computer program. 8.An application of the software fault number detection method based on the imperfect debugging model according to any one of claims 1 to 4 to large and complex software, industrial software, numerical calculation and simulation software, safety software, operating system and database basic software fault detection.

Images