Statement: The content of this document is mainly from the book "Software Debugging the way of cultivation", Paul Butcher, belongs to the reading notes.
Reproduce first, ask the second
Problem recurrence is the most powerful weapon in the empirical process, and if you can't reproduce the problem, you can't prove it.
First, follow the steps described in the Defect report, grab the key, and include three control factors
The software itself: make sure that you use the same version of the software and the bug submission, using the same compilation tools and the same compilation parameters.
Software operating Environment: If you want to interact with the external environment, make sure you use the same external system. such as rangefinder, need to be in the same lighting environment, temperature and power supply mode.
Input provided: If the software code is running and configuration parameters are relevant, the same configuration should be used.
Detailed description of the control input
The software's input may be local to the file, or it may be a series of actions by the user or a third-party device
Speculate on possible inputs:
- Backtracking: When the error location is clear, the method may be able to reproduce the problem or provide a valid clue
- Probing possible input values: using Boundary value analysis and branch coverage, experience has shown that these two are the most error-prone
- Using error conditions: When coding, human nature is concerned about the normal situation, so the unhandled error condition is likely to induce a series of bugs, so the simulation error condition may be able to reproduce the problem
- Introduce randomness: Choose a series of different input values, also called fuzzy tests. The key feature of this fuzzy tester is that you can recreate the previous input based on some column rules so that you can reproduce the problem at will
Record input values:
- Program log: There is log function in Java, can be opened or closed, C language can use independent text
- External log: This is used in the client and server-side software, the independent system can be ignored
Note Load and pressure:
- Some defects only the software under some kind of pressure to be able to show, the server-side software is most obvious, it must pass the stress test; Rangefinder software needs to be aware of the lack of battery power situation, will run error!
Improved problem reproduction
How can you make it easy and convenient to reproduce the problem and minimize the cost?
- Minimizing feedback periods:
- Minimizing problems: Minimizing the first time is unlikely, and you need to gradually remove unnecessary aspects and reduce the scope of the problem recurrence.
- Minimize the time required to reproduce: Some bugs only take time to reproduce, so you need to take steps to make them happen earlier, such as suspect resource leaks, and you can deliberately create a situation where resources are exhausted.
To turn an indeterminate defect into a definite:
- The beauty of software lies in its certainty, and there are several reasons why uncertainty often follows:
- Start in an unpredictable state: for example, C/C + + programs, using uninitialized memory or variables.
- Interacting with external systems: In this case, the best option is to use something you can control instead of an external system, such as using a serial assistant to simulate peripheral sending instructions.
- Intentional use of randomness: random functions in software, all pseudo-random, as long as the seed, the result is the same
- Multithreading: PC-side software called multi-threading, embedded end is generally called multi-tasking, can take measures to increase the competition situation, is the problem easier to achieve
Automation:
- Automated testing not only speeds up the process but also laughed at the chance to make mistakes.
- Automated testing: the need to build automated test frameworks and user-justification testing tools
- Replay log files: If you need to pass a log to reproduce the bug, you need to construct the same sequence of operations through the replay log
Iteration:
- You can use this information to continually improve your reproduction as you get more and more information about your software running during the diagnostics process. Narrowing down the range of bugs that can occur, such as narrowing to a function, a variable, or a sentence. It is easy and reliable to ensure that your recurring problems are easily and repeatedly optimized!
What if I can't reproduce it?
Does the flaw really exist?
- Users generally do not report defects maliciously, most likely the software error, it may be unclear why this, misunderstood some aspects of the software.
Solve different problems in the same area
- Are there any other flaws in the area where the problem is reproduced? If you have one, check it out. Doing so cleans up the code in the area, gives you a better understanding of the code as a whole, and finds the key factors that reproduce the problem.
Involve others in it
- Developers are prone to blind spots, and the focus is on getting the software to work correctly, rather than proving that the software is flawed, so it's necessary to involve others in it.
Make the most of your user base
- If the flaw appears in an external system, the acquisition should let the user collect important information for you, but this approach is often not ideal.
Speculate
- Although the empirical method is the best, but it is not the only solution, pure logical reasoning is one of them. This method is time-consuming and can often play a role when other methods are ineffective. The method needs to incorporate itself into the software, and at each step, consider the possibility of errors and try to explain the flaws you are tracking.
< reading notes > Software debugging: The core of the problem-reproduce the problem
