软件缺陷管理中的BUG等级划分方法.docx

软件缺陷管理中的BUG等级划分方法软件缺陷管理中的BUG等级划分方法　　BUG等级划分软件测试　　1.BUG等级划分建议：　　目前project上的BUG严重程度分为五个等级，按照CMM5中定义的规范，BUG严重等级可分为3-5个等级，由于我们公司的CMM水平还处于初级阶段，将BUG等级划分过细不符合我们当前的CMM水平，同时也不利于测试人员对BUG等级的精确划分。根据我们公司的情况，同时参照其它中小公司的等级划分标准，建议将BUG等级划分四个等级，分别为致命、严重、一般、提示。　　●致命(可对应目前BUG体系中的“非常严重”)：　　致命性问题主要为：系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。　　具体基本上可分为：　　○严重花屏　　○内存泄漏　　○用户数据丢失或破坏　　○系统崩溃/死机/冻结　　○模块无法启动或异常退出　　○严重的数值计算错误　　○功能设计与需求严重不符　　○其它导致无法测试的错误　　●严重(可对应目前BUG体系中的“严重”) 　　严重性问题主要为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。　　具体基本上可分为：　　○功能未实现　　○功能错误　　○系统刷新错误　　○语音或数据通讯错误　　○轻微的数值计算错误　　○系统所提供的功能或服务受明显的影响　　●一般(可对应于目前BUG体系中的“普通”) 　　一般性问题主要为：界面、性能缺陷　　具体基本上可分为：　　○操作界面错误(包括数据窗口内列名定义、含义是否一致) 　　○边界条件下错误　　○提示信息错误(包括未给出信息、信息提示错误等) 　　○长时间操作无进度提示　　○系统未优化(性能问题) 　　○光标跳转设置不好，鼠标(光标)定位错误　　●提示(可对应于目前BUG体系中的“轻微及建议”) 　　提示性问题主要为：易用性及建议性问题BUG 标准目的对 BUG 概念、类型划分、 BUG 状态、 BUG 严重程度等内容进行定义和规范，以便进一步指导我们的测试工作。概念BUG ：软件中存在的瑕疵，可能会导致系统失效。简单的说就是软件系统中存在的可能导致系统出错、失效、死机等问题的错误或缺陷。BUG 的类型划分功能类重复的功能多余的功能功能实现与设计要求不相符功能使用性、方便性、易用性不够界面类界面不美观控件排列、格式不统一焦点控制不合理或不全面数据处理类数据有效性检测不合理数据来源不正确数据处理过程不正确数据处理结果不正确流程类流程控制不符和要求流程实现不完整提示信息类提示信息重复或出现时机不合理提示信息格式不符和要求提示框返回后焦点停留位置不合理建议类功能性建议操作建议检校建议说明建议性能类并发量数据量压缩率响应时间常识类违背正常习俗习惯的，比如日期 / 节日等特殊类不符合 OEM 版本或 DEMO 版本特殊要求的BUG 状态已提交：测试员发现 BUG 后提交到 BUG 管理系统中的状态。(初始状态) 已修改：程序员在修改了 BUG 后提交到 BUG 管理系统中的状态。不修改：程序员或项目经理根据需求分析、概要设计、详细设计说明书等上的要求经过考虑后决定对 BUG 不进行修改。其 BUG 的状态为不修改，需要说明理由。延迟：根据目前项目进程或计划等情况，暂时延期的状态待讨论：需要进行讨论后才能决定是否需要修改的 BUG 的状态。已验证：已经解决的并经过测试员复测的 BUG 的状态。关闭：完全解决了，只供以后备查的状态重新打开：重新出现在新的版本中，重新打开以前关闭的 bug 状态( 当然在 bug 工具中，可以自己定制适合项目的状态项目，比如废除，拒绝等 ) BUG 的等级划分与优先级1 、严重：死机，数据丢失，主要功能完全丧失，系统悬挂等错误。修改优先级为最高，该级别需要程序员立即修改。2 、较高：主要功能丧失，导致严重的问题，或致命的错误声明。修改优先级为高，该级别需要程序员尽快修改。3 、一般：次要功能丧失，不太严重，如提示信息不太准确。修改优先级为中，该级别需要程序员修改。4 、轻微：微小的问题，对功能几乎没有影响，产品及属性仍可使用，如有个错别字。修改优先级为低，该级别需要程序员修改或不修改。BUG 的优先级 (一般与 BUG 等级挂钩) 参考 1 、紧急、非常高、高、中等、低参考 2 、下一个 build 版本 ,a 测试 ,b 测试 , 发布版本，最终发布版本BUG 记录内容编号标题项目模块测试阶段类型操作环境 ( 操作系统 ,IE 等软硬件环境 ) 严重程度(等级及优先级) BUG 状态测试员程序员(解决者) 解决方案解决日期测试日期详细描述(步骤、结果、期望、备注) 编号测试日期标题项目模块测试阶段测试员操作环境BUG 类型等级及优先级详细描述步骤(操作、数据输入等) 结果期望备注程序