Common Software Defect Prevention Technology and Defect Analysis Technology

Speaking of Software Defect Prevention Technology, What Is Defect Prevention? That is to say, we can eliminate defects in the bud, that is, they can be killed before they are generated, this is also the highest level pursued by software testers. A general software test is a later compensated model, and will be modified after a bug is generated. However, the later the bug is found, the higher the cost of modification will be, therefore, Software Defect Prevention Technology is the early elimination of bugs in the project lifecycle.

Generally, Common Defect Prevention involves several stages: Demand stage, design stage, and coding stage.

First, in the demand stage, the most important thing is requirement verification. Generally, the verification items are: whether the functions are complete, whether the performance is considered, whether there are fuzzy requirements, whether there are security considerations, whether there are redundant and wrong requirements, and whether the requirements are too harsh, whether the demand is contradictory or not. A common method is to list the requirement checklists and further execute the requirement/test matrix.

Second, in the design phase, technical review is used to test the logic design. A common standard practice is to create a process/data matrix, that is, a crud matrix, which shadows the process into an entity and lifecycle (creation, update, read, and delete) the data of the entire program).

Third, in the coding stage, the prevention measures at this stage mainly include unified coding specifications, code review, and unit testing. The uniform code specification is generally the uniform requirements of the Development Manager. The Code review is the mutual review or the development leader for review. The most important thing is the unit test, which is generally a white box test.

Let's talk about Defect Analysis. Many very advanced analysis technologies are not very practical. I will only introduce some common analysis methods.

1. Module Defect Distribution. Generally, a bar chart or pie chart is the ratio of bugs found in each function module. The module with the most bugs found requires more maintenance after release.

In addition, you can refer to the historical data. For example, the proportion of bugs found in the previous module is a reference for this version. If the ratio of bugs detected by a module is significantly lower than that of the previous version, it is likely that more tests are required for this module.

2. Distribution of the causes of defects. Generally, a bar chart or pie chart can be divided into architecture defects, functional defects, usability defects, performance defects, security defects, and interface text defects. Generally, if the proportion of architecture defects is large, it indicates that the design is very problematic.

3. According to the distribution of Defects of different discoverers, the bar chart or pie chart is generally divided into the tester discovery, the developer discovery, beta test discovery, external customer discovery. If the number of bugs detected by the tester is lower than a certain ratio, the quality assurance test is insufficient.

4. Distribution of defects according to different methods. Generally, there are requirements review, design testing, code lookup, Jad, manual testing, automated testing, and white box testing. In general, if you pass the Requirement Review, design test, code check, and the proportion of bugs found by Jad is very low, it indicates that the pre-test is not paid enough attention. In addition, the ratio between manual and automated testing can also indicate the contribution of automated testing.

5. The defect difference analysis shows the relationship between the detected and resolved curves. The time is the horizontal axis. The closer the two are, the higher the product quality.

6. According to the distribution of defects in the time period, it is generally expressed in a curve with a horizontal axis. It mainly shows the stage in which the most bugs are found, which is of guiding significance to the test summary.

7. the zero defect tracking method is commonly known as the enumeration analysis. Generally, the total number of defects found as of a certain time point has a function relationship with the time (a complex mathematical function ), this function is generally used to estimate the number of bugs in the software after several days of testing, and the number of bugs that may occur after being delivered to the user. However, I seriously doubt the practicality of this method, and I have never used it.

If you are not careful, Luo luocheng is so much, and hopes to help you, even if it is a little bit, and I hope you will discuss it more.

 

For more articles, visit http://www.itmarks.cn/