2024年5月2日发(作者：)

Bug定义标准

BUG定义标准

广东旭普空间信息技术产业发展有限公司

2009-10-30

文档修订记录：

版本号

V1.0

状态

C

变更内容

修改日期

2009/10/28

变更人

宋洁

*说明：C――创建，A——增加，M——修改，D——删除

广东旭普空间信息技术产业发展有限公司 第 1 页 共 8 页

Bug定义标准

1引言

1.1目的

对 BUG 概念、分类、 BUG 状态、 BUG 等级划分等内容进行定义和规范，以便进一步

指导我们的测试工作。一方面也让开发人员明白各类BUG的定义，及测试人员对其程序中各

类缺陷等级划分的依据。

1.2 概念

BUG ：软件中存在的瑕疵，可能会导致系统失效。简单的说就是软件系统中存在可能导

致系统出错、控制失效、死机等错误或缺陷。

1.3相关名词解释

1、软件错误：指在软件生存周期内出现的不希望或不可接受的人为错误。

2、软件缺陷：是存在于软件（文档、数据、程序）中偏离需求说明书的现象，其结果是软

件运行于某一特定条件时会出现软件故障。

3、软件故障：是指软件运行过程中出现的一种不希望或不可接受的内部状态，比如：软件

处于处理一个多余循环过程时，我们可以称软件出现故障，若此时没有适当的容错措施加以

处理，就会导致软件失效。

4、软件失效：软件运行时产生的一种不希望或不可接受的外部行为结果。

1.4 参考资料

1、<<测试管理—bug管理>>

2、<>

3、51testing软件测试专业论坛

2 BUG提交要求

1

2

Bug通过测试组评审，属于已确认的bug

测试人员需用清晰、简洁的文字描述bug，并能复现

广东旭普空间信息技术产业发展有限公司 第 2 页 共 8 页

Bug定义标准

3 BUG分类

1、 功能错误

以需求说明书为参照，未达到或未完成需求说明书所描述的功能即为功能错误。具体基

本上可分为：

a、严重花屏

b、内存泄漏

c、用户数据丢失或破坏

d、系统崩溃/死机/冻结

e、模块无法启动或异常退出

f、严重的数值计算错误

g、重复的功能

h、多余的功能

i、遗漏的功能

j、需求未实现

k、功能设计与需求严重不符

l、其它导致无法测试的错误

2、编码错误

在系统运行中出现各类系统报错以及出现死机、不能工作、没有反应的现象即为编码错

误。包括程序接口错误、数据流错误。

3

数据库错误

系统中各类查询数据、插入数据、更新数据时出现的数据库中表结构，视图、索引等不

对应引起的错误。通常还有数据库的表、业务规则、缺省值未加完整性等约束条件，导致进

行添加、删除、修改、查找操作后引起的报错。

4 可操作性错误

可操作性，应用方面的错误,系统操作不能连贯进行或操作步骤较复杂等。

广东旭普空间信息技术产业发展有限公司 第 3 页 共 8 页

Bug定义标准

5

界面问题

窗口各控件布局、字体显示等不美观，界面、消息提示不友好、不准确；文字输写错误、

文字内容不完整、辅助说明描述不清楚；界面同一功能图标的设计风格不统一；文字、图片、

视频等摆放位置错误，与界面内容不相符；界面功能按纽操作不方便容易误点等。

6 合理化建议

测试人员认为有更好的功能、界面、性能优化及用户易用性方面的建议。

7

8

组件错误

测试过程中需要安装特定组件导致的错误。

其它错误

系统中各类文档、帮助的错误。出现次数较少，不能复现的错误。

4 BUG生命周期管理

4.1软件错误的状态

1、新建(New)：测试中新发现的软件缺陷。

2、打开 (Open)：bug被确认并分配给相关开发人员处理。

3、修正(Fixed)：开发人员已完成修正，等待测试人员验证。

4、拒绝(Declined)：测试人员提交bug后，开发人员拒绝修改的缺陷。

5、延期(Deferred)：经评审确认不在当前版本修复的错误，下一版修复。

6、关闭(Closed)：错误已被修复。

4.2 BUG管理的一般流程

1、测试人员提交新的Bug入库，错误状态为New。

2、高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为Open。

如果不是错误，则拒绝，设置为Declined状态。

广东旭普空间信息技术产业发展有限公司 第 4 页 共 8 页

Bug定义标准

3、开发人员查询状态为Open的Bug，如果不是错误，则状态为Declined；如果是则修复。

并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。

4、对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要开会评审确认。

5、测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决则设置Bug的状

态为Closed，如没有解决置状态为Reopen。

4.3 BUG流程管理的要点

1、为保证测试人员提交bug的正确性，需要有经验的高级测试人员或测试组内部进行同行

评审，确认是否是真正的错误。

2、 测试人员需要书写准确的测试步骤并可以复现bug，对错误的处理都要保留处理信息，

包括处理名称、时间、Bug描述、处理方法、处理意见等。

3、 拒绝或延期的bug不能由程序员单方面决定，应该由项目经理、技术经理、测试组开会

评审决定。

4、 bug修复后必须由报告bug的测试人员验证无误后，确认已经修复，才能关闭。

5、 加强测试人员与开发人员的交流，对于某些不能复现的bug，测试人员可以补充详细的

测试步骤和方法，以及必要的测试用例说明。

附：下图为Bug生命周期管理详细的流程图，可供参考。

广东旭普空间信息技术产业发展有限公司 第 5 页 共 8 页

Bug定义标准

5 BUG严重程度

业界常规bug等级划分标准：

致命性—系统崩溃，数据丢失，由于程序所引起的死机、非法退出，死循环，数据库发生死

锁，错误操作导致的程序中断 ，严重的计算错误，与数据库连接错误，数据通讯错误

广东旭普空间信息技术产业发展有限公司 第 6 页 共 8 页

Bug定义标准

严重的— 操作出错，系统功能错误或遗漏；程序接口错误 、数据流错误 、轻微数据计算

错误。

中等的—程序非正常终止但可通过其它输入来避免、系统边界错误、显示报表错误、数据处

理、需求理解错误、系统文档一般错误。

一般的—错误操作提示，界面错误，打印内容、格式错误，简单的输入限制未放在前台进行

控制，删除操作未给出提示，数据输入没有边界值限定或不合理。

轻微错误—不影响系统功能，更好的操作方式，罕见的错误，辅助说明描述不清楚，显示格

式不规范，系统处理未优化，长时间操作未给用户进度提示，提示窗口文字未采用行业术语

按照CMM的标准一般将缺陷划分为3-5个等级，由于公司未开展CMM评审工作，结合公

司实际，决定把bug划分为严重错误、一般错误、轻微错误三个等级。即把致命性和严重的

合为严重错误，中等的和一般的合为一般错误。

6 BUG优先级

高（立即修证）—立即修证，修证完毕后在进行测试

中（尽快修证）—在项目上线前必须修改完

低（短期内修证）—在项目允许时间范围内修证（项目经理确认）

下一版修证—对系统运行影响不大的bug，经评审确认后可延迟到下一版本修证

附： BUG参考分类

1、 功能类

A. 重复的功能 B. 多余的功能 C. 功能实现与设计要求不相符 D. 功能使用性、方便性、

易用性不够

2、界面类

A. 界面不美观 B. 控件排列、格式不统一 C. 焦点控制不合理或不全面

3、数据处理类

A. 数据有效性检测不合理 B. 数据来源不正确 C. 数据处理过程不正确 D. 数据处理结

果不正确

4、流程类

A. 流程控制不符和要求 B. 流程实现不完整

广东旭普空间信息技术产业发展有限公司 第 7 页 共 8 页

Bug定义标准

5、提示信息类

A. 提示信息重复或出现时机不合理 B. 提示信息格式不符和要求 C. 提示框返回后焦点停

留位置不合理

6、建议类

A. 功能性建议 B. 操作建议 C. 检校建议 D. 说明建议

7、性能类

A. 并发量 B. 数据量 C. 压缩率 D. 响应时间

8、常识类

A. 违背正常习俗习惯的，比如日期 / 节日等

9、特殊类

A. 不符合 OEM 版本或 DEMO 版本特殊要求的

广东旭普空间信息技术产业发展有限公司 第 8 页 共 8 页