一、划分一个bug的等级
bug等级主要分为致命、严重、一般、轻微或者建议四个等级；
1.致命错误：系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定、价值较高功能异常（比如与金钱相关的功能）
具体基本上可分为：
（1）严重花屏
（2）内存泄漏
（3）安全问题
（4）用户权限问题
（5）网页无法正常打开
（6）严重的数值计算错误
（7）功能设计与需求严重不符
（8）系统崩溃/死机/冻结/死循环
（9）模块无法启动、调用或异常退出
（10）数据库数据丢失或破坏、数据库连接错误、发生死锁
（11）重要的一级菜单功能不能使用、无法登录、无法正常退出，程序重启、自动退出， 关联程序间调用冲突
2.严重错误：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性
具体基本上可分为：
（1）功能未实现
（2）系统刷新错误
（3）数值计算错误
（4）语音或数据通讯错误
（5）功能错误、主要功能丧失、基本模块缺失
（6）系统所提供的功能或服务受明显的影响（接口错误）
3.一般错误：界面、性能缺陷
具体基本上可分为：
（1）操作界面错误（包括数据窗口内列名定义、含义是否一致）
（2）边界条件下错误
（3）提示信息错误（包括未给出信息、信息提示错误等）
（4）长时间操作无进度提示（如导出功能）
（5）系统未优化（性能问题）
（6）光标跳转设置不好，鼠标（光标）定位错误
（7）涉及系统以及用户隐私数据没有处理或者隐藏（如密码没有隐藏化）
（8）代码在页面显示出来
4、轻微错误（建议性问题）：易用性
具体基本上可分为：
（1）界面格式等不规范
（2）页面显示重叠
（3）辅助说明描述不清楚
（4）功能描述不清楚
（5）操作时未给用户提示（如修改成功、删除成功、添加成功、加载中等）
（6）可输入区域和只读区域没有明显的区分标志（一般只读区域颜色设置较暗）
（7）个别不影响产品理解的错别字
（8）文字排列不整齐等一些小问题
（9）输入框没有限制字符数、符号等约束条件（如电话号码字段只能输入纯数字、姓名限制字符数为3-4位、身份证号码严格标准化约束）
二、bug状态
1.待处理：测试人员或者用户发现并待确认的问题
2.已确认：经测试人员及开发人员讨论后确认是BUG，并提交到缺陷管理系统（如禅道）
3.已解决：开发人员修复BUG，待测试人员验证
4.已验证：测试人员验证问题通过
5.再激活：经测试，BUG未修复成功
6.重复出现：上一个版本修复的BUG，这个版本又出现
7.设计如此：与开发人员和产品沟通后，确认不是BUG，或者建议，但是开发人员不采纳
8.暂不处理：当前版本不修改，后续版本再考虑（与开发人员确定修改日期）
三、处理bug流程
四、bug权重分配
1.一些测试leader对TE工作评估的主要依据，发现的bug数，如果仅仅是bug数并不科学，因为根据bug等级的划分，有些bug甚至没有经确认或者重复，甚至有可能出现滥竽充数的现象也说不定。
2.如果按照bug等级划分来分配权重的话，明显更加科学；
| BUG等级 | 权重 |
| 致命 | 2 |
| 严重 | 1 |
| 一般 | 0.5 |
| 轻微/建议 | 0.25 |
例如，我发现了2个致命的bug，4个提示的bug，3个建议的bug，最后的成绩=2*2+4*0.5+3*0.25
3.个人觉得，一些致命的bug或者是严重的bug（比如：一些影响到测试工作的bug等），相对比较容易发现，这些都是不具思考性的错误，为什么？因为发现这些问题，不用问，必须改的bug？难道不是这样吗？在测试日常中最难处理反而是一些建议性问题，往往更具有思考性，比如说用户需求没有说明，但是我觉得做了更能体现出用户体验的易用性，然而需求文档上没有，那就不是必须要做的，开发可以选择不做，这样开发和测试就有了争议了，那就捅到产品那里去吧。。。对于一些建议性问题往往是花费更多的时间的。
| BUG等级 | 权重 |
| 致命 | 0.25 |
| 严重 | 0.5 |
| 一般 | 1 |
| 轻微/建议 | 2 |
注意：如果产品比较成熟的话第三种比较合适，如果产品还停留在开发基本功能的情况下第二种相对比较符合。