Let's talk about the bug.

I am very grateful to Comrade "" for his recovery in the previous article, which reminds me of many problems.

As the saying goes, the treasure of a thousand miles is destroyed by the ant nest. The same is true for software. Although bugs in the software itself will not grow as slowly as the ant's point, for users, the number of errors/exceptions caused by the software will accumulate more and more, and eventually we will lose users, this causes irreparable losses. Therefore, we must pay attention to these quality problems and develop corresponding measures, plans, and solutions to prevent, test, and correct bugs.

As for how to make a test plan, how to write test cases, and so on, how to prevent "Bugs" and how to find "Bugs", what should we do after discovering "Bugs? It is not very simple to think about it.

First of all, for bugs with obvious "symptoms", once they occur, we need to record the characteristics of bugs in detail immediately. The more detailed the records, the better. For users, this is often difficult to achieve, because users often do not have this awareness, the feedback we get is often a vague bug report, such as "an error", "running to ** a sudden error prompt. For this purpose, we should establish the Defect mechanism as perfect as possible in the program for both the project and the product. In this way, the fault tolerance, robustness, and reliability of our programs can be basically guaranteed. So what content should we include in the design of the defect mechanism for bugs? I think at least we should have a log file to record the time, cause, statements or methods that cause bugs, stacks, and even context data descriptions. Of course, this is done without seriously affecting the performance. After obtaining the log file, the programmer can easily reproduce the bug and correct it.

The above is a bug that can be captured. What should I do if the error cannot be captured? Before beta testing, I think we should tell the participants that once an exception occurs, we should carefully describe the operation steps before the exception, the data used, and the prompts, even directly write the exception screenshot in the test report, which should be reflected in the test cases.

The above are some of my experiences and ideas. If I am not doing a test, I would like to give you some suggestions. I would like to provide some ideas. You are welcome to discuss them.