openSUSE:如何编写高质量的错误报告
为什么要编写高质量的错误报告
首先，我们来谈谈最重要的事情：为什么我应该费心编写（高质量的）错误报告？这很简单：因为你希望问题得到解决，对吧？其他任何事情都没有意义。
为了实现这一点，这个过程必须对所有相关人员有效。从报告者开始，到错误分类、调试、错误修复/开发、质量保证、维护、文档……最后到客户。
如果你希望错误被修复，你必须首先提供关于该问题的足够的相关信息。
什么使错误报告成为高质量的错误报告
显然，最重要的部分是错误摘要和描述。它们需要提供足够的信息，以便任何查看错误的人都能理解问题。
- 摘要需要真正概括用户所看到的问题，例如，应用程序 X 在发生 Y 时显示 Z 消息而崩溃。这有助于搜索重复项并迅速加快错误分类的速度。
- 组件必须真正符合实际情况，并非所有安装过程中发生的事情都是安装程序错误
- Assignee（负责人）通常与组件对齐，如果你更精确地知道问题的具体内容，你可以尝试自行查找错误所有者，例如，在 OBS 中
- 描述必须包含所有重要/相关信息，以便深入了解问题
- 所有关于环境的，且与问题相关的信息
- 报告者认为是什么问题的简要描述，例如，期望结果与实际结果
- 重现步骤 - 如果你无法重现它，开发人员可能也无法重现它
- 其他信息，例如，软件包的版本以及问题开始发生的时间
- 附件
- 日志（YaST/Installer/D-Installer/Agama 必需），更多信息请参见 报告 YaST 错误 关于 YaST 以及 Collecting logs 关于 Agama
- 截图（如果涉及翻译或特定语言的行为，则需要翻译成英文）。
报告者应提供所有相关信息，而无需请求。报告者的任务是首先思考并使错误报告自包含。
不要假设以后处理错误的人能够理解字里行间，并知道那些没有的信息。有些人可能无法访问内部链接，或者他们可能会消失。
什么使错误报告成为低质量的错误报告
- 报告者应该理解他们实际报告的内容。请参阅上面的为什么要编写高质量的错误报告。通过复制粘贴控制台或日志中的随机文本进行报告没有帮助。
- 请不要报告失败的 openQA 测试用例，而是报告错误。我们调试和修复错误，而不是调试或修复失败的测试用例。openQA 测试用例通常是一个相当复杂的场景，包含多个隐藏的期望、依赖项等。这些必须首先明确或消除。
- 不要仅链接一个失败的 openQA 测试，因为它们会很快消失。错误报告必须自包含，并且在 10 年后仍然可以进行审查，例如，openQA 测试结果消失得更快。请参阅上面的描述和附件。
- 不要将所有内容标记为Severity（严重性）Major（主要）甚至Critical（关键），通常并非如此。例如，Critical意味着数据丢失。将其保持在Normal（正常）通常就足够了。
- 不要报告重复的错误，先搜索。为此，其他人也需要编写高质量的错误报告。
- 不要使用通用摘要（标题），例如“openQA test test_name failed”不包含任何实际信息。请参阅上面的摘要。如果测试失败，我们可能会认为问题在于测试本身。
- 不要将仓库的错误内容、软件包冲突、构建错误的媒体、某些命令行工具的错误或超时等报告为安装程序/YaST 错误。使用更合适的内容或仅仅使用“其他”。
- 不要将功能请求报告为错误，我们有一个 工具 用于此目的。我们通常会将其关闭为 FEATURE。
- 一张图片可能胜过千言万语，但即使是图片也可能需要一些解释，不要认为没有它一切都清晰明了。描述图片包含的内容，哪里出了问题等等。
- 不要设置错误的Priority（优先级），那是项目/发布经理的任务。
低质量的错误报告会发生什么
开发人员没有无限的时间来处理错误。我们深感抱歉，但我们保留将此类错误关闭为INVALID（无效）以及我们不打算修复的错误关闭为WONTFIX（不会修复）和功能请求关闭为FEATURE（功能）的可能性。
更多阅读
学习是乐趣的一部分。只需搜索“如何编写高质量的错误报告”，就能找到更多相关信息。