本帖最后由 五折 于 2023-7-11 19:03 编辑
为大家写过软件的人大都收到过很拙劣的bug报告，例如：
在反馈中说“不好用”；所反馈内容毫无意义；在反馈中用户没有提供足够的信息；在反馈中提供了错误信息；所反馈的问题是由于用户的操作错误而产生的；所反馈的问题是由于其他程序的错误而产生的；所反馈的问题是由于网络错误而产生的；这便是为什么“技术支持”被认为是一件可怕的工作，因为有拙劣的bug反馈需要处理。然而并不是所有的bug反馈都令人生厌：我在业余时间维护自由软件，有时我会收到非常清晰、有帮助并且“有内容”的bug反馈。
==========我会尽力阐明如何写一个好的bug报告==========
我非常希望每一个人在报告bug之前都读一下这篇短文。
报告bug的目的是为了让作者看到程序的错误进而修复这个错误。你可以亲自示范，也可以给出能导致程序出错的、详尽的操作步骤。如果程序出错了，作者会复现你的错误收集额外的信息直到找到错误的原因；如果程序没有出错，那么他们会请你继续关注这个问题，收集相关的信息。
在bug报告里，要设法搞清什么是事实，例如：“我输入了ipconfig /all”和“五折这个傻Ⅹ出现了”就是事实。什么是推测，例如：“我想问题可能是出在……”。如果愿意的话，你可以省去推测，但是千万别省略事实。
请记住：如果是免费软件/脚本，作者提供给我们已经是出于好心，所以要是太多的人对他们无礼，他们可能就要“收起”这份好心了。
“程序不好用”
作者不是弱智：如果程序一点都不好用，他们不可能不知道。一定是因为程序在他们系统环境或是操作方法下工作得很正常。所以，或许是你做过一些与他们不同的操作，或者是你的系统环境与他们不同。你需要做的就是尽可能详尽的提供你真实的操作流程、系统环境、完整的报错信息。
许多程序，特别是自由软件，会公布一个“已知bug列表”。如果你遇到的bug已经在列表里了，那就不必再报告了，但是如果你认为自己掌握的信息比列表中的丰富并且该BUG尚未被修复，那无论如何也要告诉作者。你提供的信息可能会使他们更简单高效地修复bug。
本文中提到的都是一些指导方针，没有哪一条是必须恪守的准则。不同的程序员会喜欢不同形式的bug报告。如果程序附带了一套报告bug的准则，一定要读。如果它与本文中提到的规则相抵触，那么请以它为准。
如果你不是报告bug，而是寻求帮助，你应该说明你曾经到哪里寻找过答案，（例如：我搜遍了所有网站论坛，但我找不到解决的办法。）这会使作者了解用户喜欢到哪里去找答案，从而使作者把帮助文档做得更容易使用。
“演示给我看”
报告bug的最好的方法之一是“演示”给作者看。让程序员站在电脑前，运行他们的程序，指出程序的错误。让他们看着你启动电脑、运行程序、如何进行操作以及程序对你的操作有何反应。当然事实上作者会根据你提供的详细信息去复现这个报错。
他们对自己写的软件了如指掌，他们知道哪些地方不会出问题，而哪些地方最可能出问题。他们本能地知道应该注意什么。在程序真的出错之前，他们可能已经注意到某些地方不对劲，这些都会给他们一些线索。他们会观察程序测试中的每一个细节，并且选出他们认为有用的信息。
这些可能还不够。也许他们觉得还需要更多的信息，会请你重复刚才的操作。他们可能在这期间需要与你交流一下，以便在他们需要的时候让bug重新出现。他们可能会改变一些操作，看看这个错误的产生是个别问题还是相关的一类问题。如果你不走运，他们可能需要坐下来，拿出一堆开发工具，花上几个小时来好好地研究一下。
“告诉我该怎么做”
事实上，在软件使用过程中出了什么问题，作者不可能在你旁边看着。“演示”是很好的办法，但也不可能让作者看着每个出错得到人都演示一遍。所以你就要想办法让bug重现在他们面前。当他们亲眼看到错误时，就能够进行处理了。
确切地告诉作者你做了些什么。依照什么顺序操作的，精确的告诉他们你键入了什么命令并尽可能详细地提供你的每一步程序的反应。
“哪儿出错了？在我看来一切正常哦！”
如果作者按照你的反馈去复现操作丹并未报错，要么是因为你没有给他们足够的信息，要么是你的系统环境和他们的在某些地方不一样。
如果你明确看到了程序的报错信息，一定要完整的发出来，作者只需要根据报错信息修正错误，而不用自己去一步一步查找错误。
在python程序下，大部分报错都会有对应的错误消息号，一定要把这些号码告诉程序员。错误消息号包含了能被程序员读懂的各种信息，并且很有可能包含重要的线索，作者的排错工作会十分高效。
“怪了，刚才还报错，怎么现在又好了？”
“间歇性错误”其实也会出现，基于DFL本身要素很多，出现间歇性报错是让人最头疼的，这时候需要你耐心检查是不是因为自己系统环境发生了改变，是不是素材草做出了错误，比如切脸不正确、遮罩不正确等等
=============================================
小结：
bug报告的首要目的是让程序员亲眼看到错误。如果你不能亲自做给他们看，给他们能使程序出错的详细的操作步骤。
如果首要目的不能达成，程序员不能看到程序出错。这就需要bug报告的第二个目的来描述程序的什么地方出毛病了。详细的描述每一件事情：你看到了什么，你想看到什么，把错误消息记下来，尤其是“错误消息号”。
尽量试着自己“诊断”程序出错的原因（如果你认为自己可以的话）。即使做出了“诊断”，你仍然应该报告“症状”。
如果作者需要，请准备好额外的信息。如果他们不需要，就不会问你要。他们不会故意为难自己。你手头上一定要有程序的版本号，它很可能是必需品。
表述清楚，确保你的意思不能被曲解。
总的来说，最重要的是要做到精确。程序员喜欢精确。
| 
发表于 2023-7-11 19:03:01
提升卡
置顶卡
沉默卡
变色卡
照妖镜
