Arbitrary recording (software bug)

[Disclaimer: All Rights Reserved. You are welcome to reprint it. Do not use it for commercial purposes. Contact Email: feixiaoxing @ 163.com]

 

 

Due to its particularity, the software is always closely linked with bugs. Software without Bugs does not exist. Why? We know that software is done by many people, and the levels of Code completed by different people are different. Once the communication is poor, it is easy to introduce faults. In addition, the demand for software is changing at all times, software modifications are ongoing at all times, and the external hardware environment of the software is constantly changing. Even if there are no bugs in some software, it may be because we haven't found it yet. It is not very relevant to whether the software has any bugs.

In fact, as long as you enter the software development industry, you basically need to deal with bugs every day. This is not based on your will. The key to the problem is, should we do this to deal with these bug faults? What is required, what is to be improved, and what is to be rejected. Several principles should be kept in mind in the process of discovering and verifying faults,

 

(1) fault handling requires cost, and priority should be given to basic business faults;

(2) The fault must be reproduced, and the fault must be reproduced immediately or with a probability, so that the possibility of solving the problem can be greatly improved; otherwise, it is very likely that the problem cannot be solved;

(3) It is very important to describe faults. Proper and accurate descriptions can greatly increase the speed of problem solving, for example

A) What is the current software version;

B) is the fault necessary;

C) Are there any prerequisites;

D) What is the error number;

E) What is the last operation before a fault occurs;

F) What is the basic fault phenomenon.

 

Of course, you have to solve the fault. If a fault occurs, but the real cause cannot be found, this is also an annoying thing. In my personal experience, as long as the fault can be reproduced stably, it can be basically solved, but there will be some efficiency problems in the middle. Therefore, you need to pay attention to some simple principles and methods,

 

(1) Find the real cause of the fault, and find the exact location of the fault through logs and the binary method;

(2) Make full use of the log information, memory data, rollback stack, and debugging information when a fault occurs;

(3) master the single-step debugging skills and pay attention to every change in the memory data, especially when verifying that the memory is out of bounds;

(4) When solving a fault, pay attention to handling similar faults, such as faults of similar code segments;

(5) modify the fault and verify the code. Be sure not to introduce new faults. In fact, this is extremely difficult;

(6) Write test cases to prevent similar incidents. I am not doing well on my own.

 

Of course, it is easy to know what to say. It is easy to talk about many things, but it often gets a lot of discounts when it is actually implemented, which also leads to unsatisfactory results for us to handle bugs. In fact, there is no good method. The key is that we should reflect on and summarize it in time. However, it is certain that good programming habits can eliminate a number of types of faults, such as memory, deadlocks, repeated compilation, and wild pointers. I hope you will share this article with us.