简介
以下是读<<代码之殇>>的关于Bug提交的笔记，作为常识，应该是牢记于心的。Bug提交是一种确保软件质量的沟通手段，因此，信息的准确传达尤为重要。
Bug报告的定义
所有Bug报告，应该有如下要求
| 项目 | 说明 |
|---|---|
| 标题 | 要简略 |
| 指派 | 由谁来处理问题 |
| 重现步骤 | 问题再次出现的相关步骤。可采用图表、视频等。 |
| 优先级别 | 问题的紧迫程度与重要性，级别不应过多，准则应该简单，易区分，易记忆。一般可以定义 0-4 级，优先级依次降低。 |
| 严重程度 | 问题所产生的后果 |
| 解决方案 | 怎么解决问题 |
Bug 优先级
比如，可以定义如下优先级
| 级别 | 描述 | 修复时间点 |
|---|---|---|
| Pri 0 | 一个需引起关注的致命错误，不存在变通方法，是一个不可逾越的bug | 只有解决了问题，找到变通方法，才能安心。 |
| Pri 1 | 一个需要引起严重关注的致命错误 | 必须在当前冲刺阶段解决 |
| Pri 2 | 一个严重的错误 | 必须在产品发布前解决 |
| Pri 3 | 一般性错误或者建议 | 最好在产品发布前解决 |
Bug 严重程度
严重程度一般指影响范围。注意，严重程度和优先级是相互独立的。
比如，可以定义如下
| 级别 | 描述 |
|---|---|
| 1 | 引起系统崩溃或者用户数据丢失 |
| 2 | 引起故障，阻断了后续操作 |
| 3 | 引起操作不便或界面显示不完整 |
Bug 解决方案
对于解决Bug的说明。除了具体方案细节，一般也会用如下关键字进行归类，比如 已修复，无法重现，不修复，延期之类。
当一个Bug被解决，将会自行指派给发现它的人，如果解决方案不令人满意，则有可能再次被激活。