票/ bug格式有多重要？

Question

对错误报告进行格式化有多重要？它应该包含什么？

我通常会在错误报告中看到以下部分：

• 重现的步骤
• 我所看到的
• 我要看的内容
• 解释

格式化错误报告及其应包含的内容的最佳解决方案是什么？

Answer 1

最重要的是跟踪问题。如果跟踪它就不会被遗忘。

格式是锦上添花。

那说：

• 重现
的步骤
• 硬件运行
• 操作系统版本，软件版本
• 它正在做什么与应该做什么

这些很重要。

此外，永远不应删除门票，只需附上说明即可。输入票证的信息绝不应删除，只是标记为错误。这一切都与追踪问题的生命周期有关。

Answer 2

错误报告格式指南

 为了清楚地跟踪我们在Rawr中遇到的错误和功能请求，我们要求用户在向问题跟踪器发布错误时提供以下信息。

• 标题 - 这应该概述哪个类别（模型，如果它是特定于模型，或比较，优化器等高级功能），并且快速问题说明。如果不确定该类别，请将其关闭，我们将根据需要进行调整。
• 说明 - 这应该不再是一个段落，它应该快速勾勒出什么是破碎/不起作用。
• 重现步骤 - 听起来恰如其分，这些是重现相关错误的步骤。您应该从启动应用程序开始。
• 版本号/附加信息 - 您运行的是什么版本的Rawr，您的操作系统，堆栈跟踪和错误消息。请注意，大型错误消息（例如通常在Rawr崩溃期间产生的消息）应保存到error.txt文件中并附加到Issue而不是发布到描述中。这样可以为打算解决问题的开发人员提供更清晰的格式化和更少的滚动。
• 详细信息 - 在页面右侧，请填写类型（问题），版本（版本号）和组件（如果有）。
• 附件 - 附上重现问题的角色文件。

实施例

标题： [项目编辑器]项目编辑崩溃
描述：编辑舵项时Rawr崩溃。
步骤重现：

1. 启动Rawr
2. 工具＆gt;编辑项目
3. 选择血牙面膜
4. 将敏捷值从112更改为113
5. 点击“确定”按钮
6. 观察到Rawr Crashes

Answer 3

最终，格式化的目的只是为了确保人们始终包含足够的信息来重现或调试问题。如果你不强制执行某种格式，人们会使用任何想到的东西。对于对软件开发过程有充分了解的组织良好的人员，他们可能会自己包含所有相关信息。

另一方面，在许多情况下，您将从整个组织获取错误报告，甚至直接从用户那里获取错误报告。或者就此而言，有人可能只是匆忙而没有某种标准格式作为指导，你可能会得到诸如“应用程序无法正常工作”等错误报告。在一天结束时，无论如何foramt，您只需要最少量的信息来确定报告的确切问题是什么（它在何处，何时发生，如何重现）并使您能够对其进行调试。

Answer 4

我实际上认为最重要的是要确保您使用的术语易于搜索。大多数重复的错误都来自使用非标准术语。

至于确切的格式，我认为这并不重要。可以用任何格式创建一张可怕的票。

只要有助于将其引导到合适的人的基本元数据就在那里（什么组件，什么平台和重要性），其他一切都只是锦上添花，文字叙述就足够了。

我认为大多数程序员都非常善于找出可能相关的内容。如果我的网络应用程序有问题，我会报告浏览器版本，但是没有提及我正在使用的处理器数量或我的确切操作系统版本。如果我可以提炼它们，我会提到重现的步骤等。

Answer 5

Answer 6

同样重要的是理解世卫组织实际上可以查看和填充“重现步骤”等问题字段。问错人，他们会给你垃圾数据。

Some useful advice here