Further discussion: how to solve bugs

Preface:

This articleArticleIt is written based on Android customization and maintenance. Therefore, the content is related to Android, that is, the system is Android, and the language is Java. The feature is that there is no clear requirement behavior specification definition, onlyCode, A lot of behavior is also quite strange, the Code architecture is not very perfect, crash, exceptions are more common (runtimeexceptions ). Although it is based on Android, the method is generic.

What is a bug?

First, you must understand what a bug is. Different people (testing and development) may have different understandings, and different companies may have different standards. However, in general, a bug refers to unanticipated behavior (unexpected behaviors), such as crashes, exceptions, or malfunctions ), for example, if you click Save, but it is not actually saved, you click send but it is not sent successfully.
So what is the expected behavior (expected behaviors? The expected behavior usually refers to the behavior specified in the requirement specification, but many systems (such as Android) do not have any requirement or specification, so more often the criteria for judgment are knowledge and experience, or compare with other software systems. For example, although there is no requirement specification, in general, the storage should write the file or the content edited by the user into the disk file. If it fails, it can be regarded as a bug. Therefore, bugs are also subject to subjective factors.

People dealing with bugs

Ideally Program Programs Written by members (Algorithm ) Is normal, but it is proved impossible by theory. No algorithm is completely correct, and people make mistakes. Therefore, most modern software is used to ensure its correctness. Developers hand over the software to testers, and testers ensure its quality by testing bugs, when software bugs are within a certain range (less than 10), it can be determined that the software has reached the expectations, can work normally and can be released.
This process involves three groups of developers, testers, and management. Developers and testers of many large companies belong to different departments. Developers are responsible for developing testable software versions. Testers test the software and submit the software to the developers after testing the software. The developers then solve the bug. Usually they have pressure from the management and performance appraisal, that is to say, the Management said to the tester: You should submit as many bugs as possible, no matter what method you use, alternatively, you must submit three bugs each day. In addition, the tester's performance is directly related to the number of bugs submitted. The management will also say to developers: You have to remove all the bugs before milestone. Why haven't you solved the bugs last week? In addition, the performance of developers will also be related to the number of bugs. If there is an open bug, new water or bonuses will be deducted.
In this way, the original simple and pure relationship is somewhat complicated. Both testers and developers will add human nature and bring politics and utility into the system, it is common for developers to forcibly close bugs. As a result, testing and development personnel are somewhat at war:
Development: you are not a bug. Is this behavior designed like this?
Test: But this design is unreasonable!
Developer: So I am looking for the UX designer? We cannot take the lead in modifying behaviors.
Test: I do not care so much, I only test
Development: # % ^ @ & $...
....
Test: Why do you close my bug?
Development: because it cannot be reproduced
Test: But at the time I met
Development: Let's reproduce it.
Test: @ # $ % ^...

Common bug categories

As mentioned above, a bug is an unexpected behavior. Common Bugs include crashes, exceptions, malfunctions, bad user experience, and unimplemented behaviors and functions.

Recurrence rate of bugs

This is especially worth noting. First, the probability of recurrence described above is only the probability that the tester encountered a bug at the time. In addition, this is subjective, for example, if you try it once three times, some people think it is mandatory, and some people think it is a half chance (abve 50% ).
However, after several years of bug summary, we found that only the logic related to the thread sequence is the real Random bug. Other random bugs are not random. They can only be that the test is not clear about the operation steps and all the data or the current environment.

How to solve bugs

1. Find out what the bug is.

After getting a bug, don't worry about repeating it. First, you need to understand what actions and operations the bug involves, what the scene and environment were at that time, and what data was used, at which step of the Operation encountered a problem, and so on. Because the tester's description of the bug is subjective and may not be clear, it is necessary to communicate with the tester to understand these problems:
What was the current configuration, environment, and site look like?
What actions are involved?
What operations have you performed?
In which step is there a problem?
What is the problem?
What is the expected behavior?
Did the tester attach logs, screenshots, or other debugging information.
2. If the bug is crashed or abnormal
Do not reproduce it in a busy manner, because for crashes and exceptions, the log will certainly have the relevant information directly related to the crash and exceptions. Generally, this can locate the problem, for example, if the Java language encounters an exception without handle, the log will certainly contain exception-related information call stacks. The log file can be used to locate the problem. Source code . In this way, there is another clue, because you can use the source code to determine what caused this exception, what operations may be performed, and what changes have taken place in the environment, generally, this is more informative than the information provided by testers.
3. Poor user experience or unimplemented Functions
This should be communicated with testers, even with the management and designers, how to modify behaviors, how to implement behaviors, and when to make changes, generally, this developer has no right to decide.
4. Try to reproduce the bug
This step is also necessary, because even if you fix the bug, you also need to reproduce the bug for verification to ensure that you actually fix it. Therefore, if the bug cannot be reproduced, it cannot be said because it has never been reproduced or you have fixed it.
As mentioned above, if you fully understand the conditions for a bug and relevant operation steps, it is easy to reproduce the bug. The related operation steps should be described in the bug description, however, the related conditions (environment, configuration, context, and data) of the bug may need to be mined before they can be known, because the test may not be noticed, or you may forget to add it to the bug description, so the first step is to figure out the problem.
If it is a real random problem, it must be related to the thread sequence. For such problems, the cause is usually that the thread is improperly applied, and the bugs are quite hidden. The recurrence method of such problems is to find the relevant code logic and threads and perform human intervention to increase the probability of the problem, such as thread. sleep () is used to block a thread and run it in a specific time sequence to increase the probability of bug reproduction.
In addition, if it is difficult to completely copy the conditions for a bug, such as specific data or specific conditions, you can also modify the code, for example, a logic only enters when the object is empty, but in 99%, It is not empty and no data is merged to make it empty, then, empty objects are directly used in the code to reproduce bugs.
5. iteration: Guess the problem and locate the problem
The purpose of this step is to locate the source file where the problem occurs, the row or the logic. Of course, this step should be based on the recurrence of bugs.
There are also many methods to locate the problem, such as breakpoint debugging and adding logs. A common method is to add thread. dumpstack () to understand the logical call relationship of the function. This is mainly related to the software type and development environment, and many software systems cannot perform real-time debugging. Therefore, adding log files is the most common method.
6. iteration: fix and verify the problem
If a problem is identified, it can be fixed. Some problems may be easily fixed, and some problems may be complicated, depending on the specific software and specific problems. It is also possible that, especially those software with no requirement specification will find that the code is working in this way. At this time, we should discuss with the Management and Testing and designers whether this is a bug or not and whether to fix it. Of course, the most tragic thing is to find that the cause of this bug is that the system architecture design is unreasonable. At this time, we can only use other methods instead of modifying the overall architecture design, of course, this is the design of the early stage. Whether to change it depends on whether the management is allowed and the time budget is not allowed.
This is also an iterative process for fixing and verifying until the bug is perfectly fixed. That is to say, if the bug is fixed, the modification is minimal and no other bugs are triggered.
7. Submit codereview and perform codereview
Similar to development, bug fixing is also part of the development cycle, so codereview is best for quality.
The purpose of review is to minimize modifications without causing other problems. Why is modification minimized? Because the more you change, the more impact you have. If you do not have enough unit tests to verify the impact, the more likely it will lead to other problems, therefore, for bug fixing, the fewer modifications, the better, the less code the better, and the fewer modified files the better. (Of course, the ideal situation is that bugs can be solved without modifying the code ).
8. Submit the patch and close the bug.
This is the last step to solve the bug, but you must be careful, especially those who are not familiar with the development tools and version management tools used by the company, because even if your patch has been optimized, if a problem occurs in the checkin code, it is a tragedy in the tragedy. If a build error occurs, wait and get scolded!
It should be noted that all the changes are submitted to version control. It is best to pull the compilation verification from the version just in case, after the submission, first, check whether there is a build error (usually due to incomplete submission), and second, check whether there is a missed submission (the result is that the bug is not resolved ).

Summary

In the practice of programming (Program Design Practice), there is a good explanation of the bug: Debugging involves backwards reasoning, like solving murder mysteries. something impossible occurred, and the only solid information is that it really did occur. (reverse reasoning is required to solve bugs/debugging, just like detecting a bizarre murder. It seems impossible, and the only definite clue is that it does ). The process of solving the bug is indeed like this. We get a bug. It is a result. We constantly try to find clues and find out the cause. After finding the cause, we can try to fix it. We are Sherlock Holmes of the 21st century, we are ke Nan in the software industry. Looking back at the magical bugs that have been solved, it is similar to Sherlock Holmes's experience after the case is solved. It also has a sense of accomplishment and pride.

Postscript:

There is a classic book about Bug solving, the science of debugging (program debugging thoughts and practices). This book is quite practical, and the content focuses on bugs, covering all the topics required to understand bugs, detailed content, is the author's summary as a debugger for decades. In my opinion, this should be the same as the code book. Interested friends may wish to read it.