3）开发工程师根据安排对特定的Bug进行处理，找出代码中的错误原因，修改代码，重新生成产品版本。
4）开发工程师处理了Bug之后，测试人员需要对处理后的结果进行验证，经过验证确认已正确处理的Bug被标记为关闭（Close）状态。测试工程师既需要验证Bug是否已经被修正，也需要确定开发人员有没有在修改代码的同时引入新的Bug。
话说回来，网上有很多自称专家的人在那里大谈特谈所谓的优先级标准，什么“系统死机是高级别，界面错误是低级别”之类。其实这些指的是缺陷的严重级别（Serverity）！
当然，一般来说缺陷的严重级别也不是tester“主观判断”决定的，如果公司比较规范的话，会由测试经理、项目经理等组织制订这么一份相关的标准文档，文档是关于对应缺陷严重级别的定义。Tester在测试的时候就根据这么一份文档来决定对应Bug的严重级别。
我下面粘贴某公司的一个《缺陷等级标准》的文档，大家可以看到其中的“E类——测试建议”正是我上课所说的Enhancement。
========================
缺陷严重级别定义:
o 最高级--导致运行中断(应用程序崩溃),预期的功能没有得到实现,测试工作无法继续进行等.
o 紧急---事件非常重要,并且需要马上给予关注.
o 高级---事件是重要的,并且应该在紧急的事件处理之后尽快得到解决.
o 中级---事件是重要的,但是由于解决问题需要花费一定的时间,所以可以用较长的时间解决.
o 低级---事件不重要,可以在时间和资源允许的情况下再解决.
o 建议性缺陷.
更为详细的划分如下:
A类——严重错误，包括：
o 由于程序所引起的死机,非法退出
o 死循环
o 导致数据库发生死锁
o 数据通讯错误
o 严重的数值计算错误
B类——较严重错误，包括：
o 功能不符
o 数据流错误
o 程序接口错误
o 轻微的数值计算错误
C类——一般性错误，包括：
o 界面错误(详细文档)
o 打印内容、格式错误
o 简单的输入限制未放在前台进行控制
o 删除操作未给出提示
D类——较小错误，包括：
o 辅助说明描述不清楚
o 显示格式不规范
o 长时间操作未给用户进度提示
o 提示窗口文字未采用行业术语
o 可输入区域和只读区域没有明显的区分标志
o 系统处理未优化
E类——测试建议（非缺陷）
文章来源于领测软件测试网 https://www.ltesting.net/
