如何以聪明的方式报告错误
我想编写（或找到）一个类似于 ESR 风格的有效错误报告指南 如何以聪明的方式提出问题
对于有效的错误报告，您的主要技巧是什么？
I want to write (or find) a guide to effective bug reporting in a style similar to ESR's How To Ask Questions The Smart Way
What are your top tips for effective bug reports?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
最重要的是，当 bug 出现时，您必须进行一定程度的批判性思维遇到。 一旦你排除了所有可能是你的错的可能性，就写一个错误。 如果你发现这是你的错，但你正在使用/测试的软件可以做一些更有用的事情来表明这是你的错，仍然写一个错误。
此外，要成为一名真正优秀的错误报告者，您必须帮助那些测试错误的人帮助他们重新创建错误。 很可能您刚刚“掌握了重现该错误的技巧”，并且可能有一些您没有意识到的步骤。 你不能只是抱怨然后走开，参与这个过程并通过测试、重新创建和故障排除来帮助团队解决问题。
The bottom line is you have to engage some level of critical thinking when the bug is encountered. Once you've exhausted all possibilities that it could be your fault, write up a bug. If you find out its your fault, but the software you are using/testing could have done something more usable to indicate its your fault, still write a bug.
Also, to be a truly great bug-reporter, you must avail yourself to those testing the bug to help them recreate it. Its likely you've just "got the knack" for recreating that bug and there may be steps you are not conscious of. You can't just complain and walk away, participate in the process and help the team out by testing, recreating, and troubleshooting.
报告可观察到的事实然后您对这些事实的解释。
有时，最好的错误报告包括对问题理解的直觉。 仅事实错误报告会削弱这一宝贵的人力资源。
Report the observable facts and then your interpretation of those facts.
Sometimes the best bug reports include something that is a gut feel of an understanding of the problem. Facts-only bug reporting discounts this valuable human resource.
我们的 QA 人员常常认为他们可以将在一张票上说，这是我的例外，没有任何备份文档。 如果没有更多信息，几乎不可能重现，更不用说解决问题了。
Too often, our QA people think they can just put in a ticket saying, here's my exception without any backup documentation. Its near impossible to reproduce let alone fix the issue without more information.
不要假设错误报告的读者和您一样了解该软件。 即使是编写该软件的人，如果自编写该软件以来已经过去了足够长的时间，也可能不知道您在说什么。 编写它以便任何人都可以理解并重现该问题。
Don't assume the reader of your bug report knows the software as well as you do. Even the person who wrote the software may not know what you are talking about if enough time has passed since they wrote it. Write it so that anyone can understand and reproduce the problem.
对于所有没有重现步骤就不会查看某些内容的人：
我的第一份编程合作社工作分配给我一个错误，该错误本质上是一个随机竞争条件，导致系统不稳定。 它发生在系统执行的任何时刻，我们所拥有的只是一些堆栈跟踪，指向一段显然很好的代码。 某个地方另一个线程正在处理不应该的数据，如果这个线程处于正确的位置，它就会崩溃。 我们的 QA 大约每月都会崩溃一次。 我们花了两周时间梳理系统才找到罪魁祸首（是的，对共享资源的未经检查的访问，大约需要 2 行修复）并修复它。 从来没有一个像样的步骤来重现，因为没有通用的方法来重现它（保存将一堆yield（）推到正确的位置）。 如果您要在多线程系统上工作，您最好准备好处理无法可靠重现的错误，可能没有稳定的重现步骤，而不仅仅是因为无法重现错误而向 QA 抱怨。
请注意，上述内容并不是 QA 在可能的情况下不包含尽可能多的细节的借口，只是指出这在现代软件中并不总是可能的。
For all the people who won't look at something without steps to reproduce:
My first programming co-op job I was assigned a bug that was essentially a random race condition that was making the system unstable. It happened at any point in the system execution, and all we had were a few stack traces pointing to a section of code that was pretty obviously fine. Somewhere another thread was mucking about with data it shouldn't be and if this thread was at the right point it would crash. Our QA got crashes about once a month. It took two weeks of combing through the system to find the culprit (yup, unchecked access to shared resources, about a 2 line fix) and fix it. There never was a decent steps to reproduce because there was no general way to reproduce it (save shoving a bunch of yield()'s in the right spot). If you're going to work on a multithreaded system, you better be ready to deal with bugs that can't be reproduced reliably, may not have stable steps to reproduce, and not just whine to QA because you couldn't reproduce the bug.
Note that the above is no excuse for QA to not include as much detail as they can when possible, just pointing out that it isn't always possible on modern software.
写出重现错误的步骤。 如果你无法重现它，它就不会得到修复。
Write the steps to reproduce the bug. If you can't reproduce it, it won't get fixed.