《软件缺陷(bug)的概述及书写规范》由会员分享，可在线阅读，更多相关《软件缺陷(bug)的概述及书写规范（5页珍藏版）》请在金锄头文库上搜索。
1、软件缺陷（bug）的概述及书写规范1、软件缺陷（、软件缺陷（bug）的定义）的定义IEEE（ 1983） 729 软件缺陷一个标准的定义：从产品内部看：软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题。从产品外部看：软件缺陷是系统所需要实现的某种功能的失效或违背。2、软件缺陷（、软件缺陷（bug）满足的）满足的 5 个规则个规则至少满足以下 5 个规则之一，才称为发生一个软件缺陷： 软件未实现产品说明书要求的功能 软件出现了产品说明书指明不应该出现的错误 软件实现了产品说明书未提到的功能 软件未实现产品说明书虽未明确提及但应该实现的目标 软件难以理解，不易使用，运行缓慢或者-最终
2、用户会认为不好3、软件缺陷（、软件缺陷（bug）生命周期）生命周期测试人员开发人员测试人员测试人员提交 bug处理 bug置 bug 为 fixed回归测试YNYN4、软件缺陷（、软件缺陷（bug）状态）状态Unfixed测试人员新建一个 bug，将 bug 的状态定义为 unfixed，开发人员看到的最新的 bug 状态都是 unfixed。To be fixed开发经理将新建的bug指派给自己或者其他开发人员， 将bug的状态置为 to be fixed。Pending由于该 bug 实现比较难，或者无法修改，开发人员会将 bug状态置为 pending。To be verified开发人
3、员已修复 bug，将该 bug 指派给其他开发人员，进行内部测试，此时 bug 状态为 to be verified。Verified开发人员进行内部测试确认该 bug 已修复，然后将该 bug 指派给测试经理，bug 状态置为 verified。Integrated测试经理将已修复 bug 指派给 bug 提交者，做回归测试，此时将 bug 状态置为 integrated。Fixed测试人员进行回归测试，确认 bug 已修复，将 bug 状态置为fixed。Close该 bug 不是 bug，或者描述有误，开发经理关闭该 bug，此时 bug 状态为 close。5、软件缺陷（、软件缺陷（b
4、ug）的优先级）的优先级High（高优先级）（高优先级）严重花屏内存泄露用户数据丢失或破坏系统崩溃/死机/冻结模块无法启动或异常退出严重的数值计算错误功能设计与需求严重不符其他导致无法测试的错误Mid（中优先级）（中优先级）功能问题系统刷新错误语音或数据通讯错误轻微的数值计算错误界面操作错误边界条件下错误系统运行缓慢、等待时间过长图片按钮显示错误Low（低优先级）（低优先级）界面格式不规范操作时未给用户提示可输入区域和只读区域没有明显的区分标志个别不影响产品理解的错别字文字排列不整齐等一些小问题建议性问题6、软件缺陷报告（、软件缺陷报告（Bug）的书写规范）的书写规范Bug 描述的目的是尽最大
5、可能帮助开发人员解决 bug，所以 bug 描述要尽可能丰富但切中要害，使开发人员能迅速定位 bug 产生的原因。主题主题用一个简短的句子描述问题，不要写成一大段以进入问题模块路径开头，方便开发经理分派任务，以及开发人员定位问题描述问题时要详细、简练、抓住要点，直接切入正题，不要罗嗦不要夸大或缩小问题的严重程度描述描述描述 bug 产生的基本环境用数字编号，一步步的描述重现问题的所有操作步骤提供明确的再现问题的步骤，避免问题被以“不能重现”关掉设置区域需要描述，如：各设置项值为默认、*值更改为“”，其他设置项值为默认 尽量用动词作为开头，描述每个步骤。如：打开、点击、设置、选择、插入、双击等不
6、要在一个步骤中描述不相关的多个操作。如果是相关的一系列操作，可以使用“”来连接描述按照你写的步骤去执行，看问题能否重现不要在步骤中使用含糊不清的缩写词描述实际结果实际结果实际只描述一个问题同样的操作步骤产生多种现象，要在一条 bug 报告中加以描述不同的操作步骤产生不同的问题，分别报 bug如果有截图，列出所附的图片信息期望结果期望结果如果有必要，列出期望的结果不要加入实际结果的描述信息描述要清晰，不要使用含糊不清的缩写词描述如果有截图，列出所附的图片信息备注备注避免写成大段落，要写的简单、易读问题的特征出现问题后的解决方法对终端客户的影响情况如果有必要，列出产生问题的配置环境附件附件提供附图便于确认错误的表现形式和错误的位置7、描述缺陷报告（、描述缺陷报告（bug）的技巧）的技巧在脑海中有明确的对象多花一些时间来验证清楚写完 bug 后要自己读一遍让他人读你写的 bug不要加入评论性语句充分使用已有的标准模板Bug 优先级要分好类
