“Show me.”
One of the best ways to report a bug is to “demo” it to the programmer. Get programmers to stand in front of a computer, run their programs, and point out their mistakes. Let them watch you start the computer, run the program, how you do it, and how the program reacts to your input.
They know the software they write inside out, they know what won’t go wrong and what’s most likely to go wrong. They instinctively know what to look out for.
They might have noticed something was wrong before the program actually went wrong, which would give them a clue. They observe every detail of the program’s tests and select the information they find useful.
That may not be enough. Perhaps they feel they need more information and ask you to repeat. They may need to communicate with you in the meantime so that bugs can resurface if they need to.
They may change some operations to see if the error is an isolated problem or a related kind of problem.
If you’re unlucky, they might need to sit down, pull out a bunch of development tools, and spend a couple of hours digging through them. But the most important thing is to have the programmer at the computer when something goes wrong.
Learn C/C++ programming knowledge, improve C/C++ programming ability, welcome to pay attention to UP to grow together!
In addition, UP has uploaded some video tutorials on how to learn C/C++ programming on its homepage. If you are interested or studying, please check them out. It will help you
Finally, if you want to be a programmer and want to learn programming quickly, join the Learning Penguin community!
There are senior professional software development engineers, online answer all your doubts ~ programming language introduction “So easy”
Programming learning materials
Once they see a problem, they usually find the cause and start trying to fix it.
“Tell me what to do.”
This is the age of the Internet, the age of information exchange. Tell the programmer exactly what you did. If it’s a graphical application, tell them which buttons you pressed and in what order.
If it’s a command line program, tell them exactly what command you typed. You should provide as much detail as possible about the responses to the commands and programs you type.
Tell programmers all the input options you can think of; if a program reads a file, you may need to send them a copy of the file.
If the program needs to communicate with another computer over the network, you may not be able to copy that computer, but you can at least say what type of computer it is and what software it has installed (if you can).
“When things went wrong, I did…”
There are many things you can do when an error or bug occurs. But most people make things worse. When something goes wrong, stop whatever you’re doing.
Don’t press any buttons. Take a close look at the screen, notice anything that’s not normal, memorize it or write it down. Then carefully click “OK” or “Cancel” and choose the safest one.
Learn to have a knee-jerk reaction — if something goes wrong with your computer, don’t bother. To get rid of the problem, it is not good to shut down the affected program or restart the computer. A good way to solve the problem is to let it happen again.
Programmers love problems that can be reproduced, and happy programmers fix bugs faster and more efficiently.
“Is really strange, a moment ago still not good, how now good again?”
“Intermittent errors” are a real worry for programmers. By comparison, the problem of doing a simple set of actions that can cause an error is simple. The programmer can repeat those operations under conditions that are easy to observe, observing every detail.
Too many problems can’t be solved in this situation, for example: the program bugs once a week, or occasionally, or never bugs in front of the programmer (as soon as the programmer leaves). (translator). And, of course, the deadline for the program is up, so it’s bound to go wrong.
Most “intermittent errors” are not really “intermittent”. Most of these errors are connected somewhere. Some errors may be caused by memory leaks, some by other programs modifying an important file at the wrong time, and some may occur in the first half hour of each hour (I’ve actually experienced this).
Programmers want to know anything about the problems you find. If possible, try it on another machine several times, two times, three times to see if the problem occurs more often. If the problem occurs after you have done a series of operations and you don’t want it to, it could be the result of running for a long time or working with large files.
When the program crashes, try to remember what you did, and if you see any graphics, mention them. Anything you can offer will be helpful.
Even a general description (for example, when EMACS is running in the background, the program often fails) may not provide a direct clue as to what caused the problem, but it may help the programmer reproduce it.