BUG生命周期及优先级、严重级划分.docxVIP

Yes关闭（Closed）（ Yes 关闭（Closed） （New） 拒绝 打开（Open） 重新打开 解决（Fixed） 黑盒测试用例的设计方法 第一章 BUG 生命周期 测试人员提交 BUG 是否打开 开发负责人判定 BUG 并 分配给相应的开发人员  （Rejected） 开发人员解决 BUG （Reopen） N0 测试人员验证 BUG 是否已解决 是否关闭 Yes 对 BUG 处理 开发负责人：对每条 BUG 进行分配，标注处理意见，给定优先级。问题分配时，应可能将 咨询类、理解错误类等问题处理掉，而不是直接打开，分配给开发人员。有可能是需求问 题，分配给需求人员。把状态置为：Open 或者 Rejected. 开发人员：分析 BUG，写出问题原因，修改 BUG；实行 BUG 优先原则，严重程度高优先修改， 修改完成后，把 BUG 状态置为：Fixed. 测试人员：对修改问题进行验证后，验证通过后把 BUG 状态置为：Closed；验证不通过， 把 BUG 状态置为：Reopen。 第二章 严重级别划分 Urgent：致命错误 致命错误通常有如下情况： 需求书中的重要功能未实现； 造成系统崩溃、死机,并且不能通过其它方法实现功能； 常规操作造成程序非法退出、死循环、通讯中断或异常，数据破坏丢失或数据库异常、 且不能通过其它方法实现功能的。 Very High：严重错误 严重错误通常使系统不稳定、不安全、或破坏数据、或产生错误结果，而且是常规操作中 经常发生或非常规操作中不可避免的主要问题，如： 重要功能基本能实现，但系统不稳定、一些边界条件下操作会导致 run-time error、 文件操作异常、通讯异常、数据丢失或破坏等错误； 重要功能不能按正常操作实现，但可通过其它方法可实现； 错误的波及面广，影响到其它重要功能正常实现； 密码明文显示； C/S、B/S 模式下，利用客户端某些操作可造成服务端不能继续正常工作的。 High：一般错误 程序的功能运行基本正常，但是存在一些需求、设计或实现上的缺陷；次要功能运行不正 常，如： 次要功能不能正常实现； 操作界面错误（包括数据窗口内列名定义、含义不一致）； 打印内容、格式错误； 查询错误，数据错误显示； 简单的输入限制未放在前台进行控制； 删除操作未给出提示； 数据库表中有过多的空字段； 因错误操作迫使程序中断； 找不到规律的时好时坏； 数据库的表、业务规则、缺省值未加完整性等约束条件； 经过一段时间运行后，系统性能或响应时间会变慢； 重要资料，如密码未加密存放（包括配置文件中的密码），或其它存在安全性隐患的； 硬件或通讯异常发生恢复后，系统不能自动正常继续工作（需要过多的人工干预才行） ； 系统兼容性差，与其它支持系统一起工作时容易出错，而没有充分理由说明是由支持 系统引起的；或者由于使用了非常规技术或第三方组件造成不能使用自动化测试工具进行 测试的。 Medium：细微错误 程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误，如： 界面不规范； 辅助说明描述不清楚； 输入输出不规范； 长操作未给用户提示（或长操作结束后提示没有消失）； 提示窗口文字未采用行业术语； 可输入区域和只读区域没有明显的区分标志； 界面存在文字错误； 在功能实现方式上如果需求中没有明确定义，而没有按常规实现，并且不比常规方式实 现优越的；( 如用户名第一位用数字或特殊字符) Low：改进建议 可以提高产品质量的建议，包括新需求和对需求的改进。 第三章 严重级划分 ? ? ?  立即解决（Resolve Immediately）缺陷必须被立即解决。 正常排队（Normal Queue）缺陷需要正常排队等待修复或列入软件发布清单。 3.不紧急（Not Urgent）缺陷可以在方便时被纠正。