Question
The more you understand your opponent, the bug, the better your test will be, and the more reliable the software quality will be.
Although it is difficult to apply the experience data of other organizations to your organization, and even some data is opposite to intuition, you need to take actions and evaluate your situation using some methods, to improve.
Uneven bug Distribution
Without analysis, the natural idea is that the distribution of bugs will be scattered, and the probability will exist in the whole system. In fact, the classic 2-8 principle is still valid here:
20% class/sub-Program80% of bugs exist. In other words, 20% of classes/subprograms occupy 80% of the development cost. Some people even find that 50% of bugs exist in 5% of classes;
According to some materials, IBM's analysis of its OS/360 operating system found that only a few vulnerable subprograms per thousand linesCodeUp to 50 bugs are fixed at 10 times the cost of developing the entire system (this cost includes customer support and on-site maintenance)
Because of the complexity of classes/subprograms in the bug set, we need to consider reducing the complexity during design. We should consider refactoring solutions that have been developed.
The impact of most bugs is limited.
The study found that 85% of bugs can be modified within the scope of a class/subroutine.
Most bugs are easily fixed.
A bug of about 85 can be fixed within several hours; a bug of about 15% takes several hours to a few days; a bug of less than 15 takes a longer time;
Programmer error understanding of design-caused bugs
Some research shows that 16% of bugs are caused by this cause, and another research result shows that this causes 19% of bugs. Therefore, it is worthwhile to take some time to thoroughly understand the design.
Three most common bug sources besides software design coding:
Lack of application knowledge;
Frequent changes or conflicting demands;
Ineffective communication and coordination;
Distribution of bug sources during the software design component period is:
95% of bugs are caused by program developers, 2% of system software, 1% of hardware, and 2% of other software;
Especially, spelling errors are a common bug source.
For different types of software systems, the difference between spelling and spelling is large, ranging from 4% to 36%.
Think about the three most expensive software bugs that humans have ever created-$1.6 billion, $0.9 billion, and $0.245 billion-all because of an incorrect character.
I used to make it difficult to spell a user as uesr. I accidentally found a bug in spelling organization as organiztion when I checked the database data yesterday afternoon.
With industry experience, 1-25 bugs are detected in thousands of lines of code on average in most released software.
Microsoft has 10-20 defects in the internal testing of thousands of lines of code, and the number of released products is reduced to 0.5.
Defense and aerospace systems can achieve zero bugs per 0.5 million lines.
A report claims that a development team Using TSP can reach the level of 0.06 bugs in thousands of lines of code.
In addition to special types of software systems, developing high-quality software generally costs less than developing low-quality software and then correcting it.
How long does it take to stop debugging? -- This is a very valuable and worthwhile goal