BUG 参考标准(网络转载)
一、目的
对 BUG 概念、类型划分、 BUG 状态、 BUG 严重程度等内容进行定义和规范，以便进一步指导我们的测试工作。
二、概念
BUG ：软件中存在的瑕疵，可能会导致系统失效。简单的说就是软件系统中存在的可能导致系统出错、失效、死机等问题的错误或缺陷。
三、 BUG 的类型划分
• 功能类
A. 重复的功能
B. 多余的功能
C. 功能实现与设计要求不相符
D. 功能使用性、方便性、易用性不够
• 界面类
A. 界面不美观
B. 控件排列、格式不统一
C. 焦点控制不合理或不全面
• 数据处理类
A. 数据有效性检测不合理
B. 数据来源不正确
C. 数据处理过程不正确
D. 数据处理结果不正确
• 流程类
A. 流程控制不符和要求
B. 流程实现不完整
• 提示信息类
A. 提示信息重复或出现时机不合理
B. 提示信息格式不符和要求
C. 提示框返回后焦点停留位置不合理
6 、建议类
A. 功能性建议
B. 操作建议
C. 检校建议
D. 说明建议
7 、性能类
A. 并发量
B. 数据量
C. 压缩率
D. 响应时间
8 、常识类
A. 违背正常习俗习惯的，比如日期 / 节日等
9 、特殊类
A. 不符合 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 类型 |
|
等级及优先级 |
|
|
|
详细描述 |
||||
|
• 步骤（操作、数据输入等） |
||||
|
程序员 |
|
解决日期 |
|
|
|
解决方案 |
||||
|
|
||||
备注：根据项目具体情况，定制真正适合项目的 bug 规范，一切以提高产品质量及公司效益为根本， bug 没有统一规范只有共同的目的。
