大多数公司都是用bugzilla来管理bug，也有的公司使用内部开发的bug管理平台。这里以bugzilla为例，我最不爽的是提bug的时候既要选择severity（严重级别）又要选择priority（优先级别），实际工作中severity很少用得上，因为大多数开发人员都是根据priority来进行修复的，比如经过N步操作+N种牛角尖式使用找到一个崩溃bug，它严重程度很高，但是因为在实际用户那里根本不会遇到这种情景，则它的优先级就很低，而开发和产品的意见往往就是“根据用户反馈再做修改”，这种bug往往修改难度也很大，看起来很严重，实际根本遇不到，或者说百年一遇，如果需要花大力气去修改，实在不合算，可能还会影响性能。有鉴于此，我认为提bug的时候考虑它的优先级就够了，severity留个默认值即可，现在大多公司在产品发布前都有三方对bug会议，在提bug的时候分得太细除了影响效率没有太多用途，如何按优先级别提bug呢，以我们部门为例，大概如下列表所示。
| P0 | 1.导致系统蓝屏、卡死 2.程序毕现崩溃、严重资源泄露等 3.产品整体无法测试 4.功能无法测试 |
| P1 | 1、子功能无效 2、子功能不符合需求 3、一级页面的明显的界面问题，页面错位，大图错误等 4、较明显性能问题 |
| P2 | 1、某些测试用例结果不符合预期的功能问题 2、不明显的界面问题，如二级页面以下的界面问题，文字问题等 |
| P3 | 1、影响体验和功能的产品建议 2、无法重现且无dump的崩溃问题 |
| P4 | 1、一般的产品建议 |
