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没有统一规范只有共同的目的。