bug定义标准
BUG级别（优先级、严重级）定义
BUG级别（优先级、严重级）定义⼀、主要分类BUG类型标准主要分两类：Ø 依据优先级分类。
Ø 依据严重程度分类。
⼆、主要内容依据优先级分类标准定义优先级：指⼀个BUG相对于其他BUG对于公司的影响，解决的及时性。
分类标准紧急² 系统⽆法⼯作² 测试⽆法继续正常⼯作² 特殊情况：如重要客户（项⽬重要性）⾼² 需求问题² 实现与需求不符² 出现调试代码² 功能性错误² 关联性错误² 前后模块不⼀致² 链接错误² 特殊性的程度性能低下² 程序引起的安全问题注：涉及所有关于数据流的错误中² 页⾯格式错误² 兼容性问题² 校检错误² 图⽚错误² ⽂案错误² 程序性能低下² 缺少容错性处理² 功能易⽤程度低² 配置问题注：涉及的所有关于⽂本的错误低² 遗留问题² 暂时⽆法实现技术问题² 合理建议依据严重程度分类标准定义严重程度：指⼀个BUG对于⽤户造成的影响，风险和可视性。
分类标准紧急² 程序⽆法运⾏的错误² 测试⽆法执⾏的错误⾮常⾼² 链接错误² 前后模块不⼀致² 需求问题² 实现与需求不符² 出现调试代码² 功能性错误² 程序性能低下² 程序引起的安全问题⾼² 页⾯格式错误² ⽂案错误² 图⽚错误² 兼容性错误² 校检错误中² 关联性错误² 配置问题² 功能易⽤程度低低² 合理建议² 遗留问题² 暂时⽆法实现技术问题注意事项1) ⼀些错误可以分在多个级别中，但总的标准以此为准，具体的问题具体分析后再确定其等级数。
bug优先级定义标准
bug优先级定义标准Bug优先级定义标准是一个用于确定和组织软件缺陷修复顺序的系统。
这个标准可以根据缺陷的严重程度、影响范围和紧急性进行评估和排序。
通过定义和遵循一套统一的标准，团队可以更好地管理和解决各种缺陷，确保关键问题得到及时解决，同时也能够更好地分配资源和时间。
一般来说，一个完善的Bug优先级定义标准应包括以下几个关键要素：1. 严重程度（Severity）：指的是缺陷对系统功能或性能的重大影响程度。
常见的严重程度分级可以是致命（Critical）、严重（Major）、一般（Minor）和轻微（Trivial）等。
这些级别通常是根据缺陷对用户体验、系统稳定性和关键功能的影响程度来定义的。
2. 优先级（Priority）：指的是修复该缺陷的紧急程度。
通常使用高、中、低等级别来表示。
优先级的确定可以考虑到缺陷对用户的影响、缺陷的复现频率、工作量以及项目进度等因素。
3. 影响范围（Impact）：指的是缺陷对系统其他功能或模块的影响程度。
评估缺陷的影响范围可以帮助团队更好地理解和评估修复该缺陷的优先级。
4. 复现频率（Reproducibility）：缺陷的复现频率可以作为评估优先级的参考因素之一。
如果一个缺陷容易被复现，可能会被赋予更高的优先级，因为它对用户和系统的影响更大。
5. 解决时限（Deadlines）：指定某些缺陷需要在特定时间内得到解决的情况。
根据项目的需求和进度，团队可以设定不同的修复时限来确定优先级。
通过以上要素的评估和综合考虑，团队可以为每个缺陷确定一个准确的优先级，从而能够更好地管理和解决系统中的问题。
举个例子，假设有一个软件中存在一个导致系统崩溃的缺陷，这个缺陷导致用户无法完成关键操作。
在这种情况下，这个缺陷在严重程度上应该被定义为致命（Critical），因为它会导致系统不可用，直接影响用户体验和业务流程。
在优先级上，这个缺陷应该被赋予高优先级，尽快解决并发布修复版本。
BUG等级划分标准
B U G等级划分标准 Prepared on 22 November 2020BUG等级划分方法一、测试BUG等级划分标准1、Blocker（崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。
如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。
2、Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。
功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。
如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。
3、Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多，合理安排解决BUG，解决率关系版本的优化程度)4、Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。
如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）二、BUG状态标准1、待处理（new）：测试人员或用户发现新问题后提交的状态2、已确认（open）：经测试人员及研发人员讨论后确认是BUG，提交的状态，由测试人员来设置。
3、已处理（fixed）：经研发人员确认是BUG后修复的状态，修改还没有验证，由开发人员来设置。
BUG管理规范
BUG管理规范一、引言在软件开辟的过程中，难免会浮现各种各样的错误和缺陷，这些错误和缺陷被称为BUG。
为了更好地管理和解决这些BUG，制定一套科学合理的BUG管理规范是非常必要的。
本文将介绍一套BUG管理规范，包括BUG的定义、分类、报告、跟踪、解决和验证等方面的内容。
二、BUG的定义BUG是指在软件开辟、测试或者使用过程中发现的与预期功能不符的问题或者错误。
它可能导致软件的功能不完善、性能下降、安全问题等。
三、BUG的分类为了更好地管理和解决BUG，我们将其分为以下几类：1. 功能缺陷：指软件功能与需求不符或者无法正常使用的问题。
2. 数据错误：指软件在处理数据时浮现的错误或者异常。
3. 用户界面问题：指软件界面设计不合理、不美观或者不易用的问题。
4. 性能问题：指软件在运行过程中浮现的卡顿、响应慢等性能方面的问题。
5. 安全问题：指软件存在的漏洞、易受攻击或者数据泄露等安全方面的问题。
四、BUG的报告1. 报告人员：任何人都可以报告BUG，包括开辟人员、测试人员、用户等。
2. 报告方式：BUG应以书面形式进行报告，包括BUG的标题、描述、重现步骤、期望结果和实际结果等信息。
3. 报告的内容：- BUG的标题应简明扼要地描述问题的关键信息。
- BUG的描述应详细描述问题的现象、影响和可能的原因。
- 重现步骤应详细描述如何重现该BUG，以便开辟人员能够准确复现问题。
- 期望结果应描述在没有BUG的情况下，软件应该达到的预期结果。
- 实际结果应描述在浮现BUG的情况下，软件的实际表现。
- 报告人应提供相关的软件版本、操作系统、硬件环境等信息，以便更好地定位和解决BUG。
五、BUG的跟踪1. 分配责任：BUG应由专门的人员进行跟踪和处理，该人员应负责分配BUG 给相应的开辟人员进行解决。
2. 跟踪方式：可以使用专门的BUG管理工具进行BUG的跟踪，如JIRA、Bugzilla等。
3. 跟踪内容：- BUG的状态：包括新建、分配、解决、验证等状态，以便记录和追踪BUG 的处理过程。
BUG管理规范
BUG管理规范一、引言在软件开辟过程中，难免会浮现各种各样的缺陷和问题，这些问题被称为BUG。
为了更好地管理和解决BUG，提高软件质量和用户体验，制定和遵守BUG 管理规范是必要的。
本文将详细介绍BUG管理规范的相关内容。
二、BUG管理流程1. BUG的定义BUG是指软件或者系统中存在的功能缺陷、设计缺陷、逻辑错误、性能问题等与预期不符的现象。
2. BUG的分类根据BUG的性质和影响程度，将BUG分为以下几类：- 严重BUG：导致系统崩溃、数据丢失或者无法正常使用的BUG。
- 普通BUG：影响系统功能或者用户体验，但不会导致系统崩溃或者数据丢失的BUG。
- 轻微BUG：对系统功能和用户体验影响较小的BUG。
3. BUG的发现和报告- 开辟人员在开辟和测试过程中发现BUG，应即将记录并报告给测试人员。
- 测试人员在测试过程中发现BUG，应即将记录并报告给开辟人员。
- 用户在使用过程中发现BUG，应提供详细的BUG描述，并报告给相关人员。
4. BUG的记录和跟踪- 每一个BUG应有惟一的标识符，用于跟踪和管理BUG的整个生命周期。
- 记录BUG时，应包括以下信息：- BUG的标题：简明扼要地描述BUG的内容。
- BUG的描述：详细描述BUG的现象、重现步骤和影响。
- BUG的优先级：根据BUG的严重程度和影响，确定BUG的优先级。
- BUG的状态：初始状态为“未确认”，经确认后可改为“已确认”。
- BUG的责任人：指派负责解决该BUG的人员。
- BUG的解决方案：记录解决该BUG的方法和步骤。
- BUG的解决时间：记录解决该BUG的时间。
5. BUG的解决和验证- 负责解决BUG的人员应及时处理并解决BUG。
- 解决BUG后，应进行验证测试，确保BUG已被修复。
- 验证测试通过后，将BUG的状态改为“已解决”。
6. BUG的关闭和归档- 经验证测试确认BUG已解决后，将BUG的状态改为“已关闭”。
- 关闭的BUG将被归档，以备后续参考和分析。
Bug等级和定义
Bug等级/定义
等级修改完成时长验证完成时长
紧急2工作日1工作日
非常高3工作日2工作日
高4工作日3工作日
中5工作日4工作日
低6工作日4工作日
5级分类
A类（紧急）---导致系统崩溃、死机；出现不可挽救的数据丢失或损坏、内存泄露
1.系统崩溃。
如：应用程序死掉、应用程序异常退出
2.无法正常安装
3.升级脚本错误，升级失败
4.主要功能无法实现或遗漏，流程执行受阻等
……
B类（非常高）---导致程序模块丢失或未实现；软件错误导致数据丢失；用户需求未实现
1.基本功能存在部分问题或基本功能无法实现或遗漏
2.程序抛出异常
3.安装后文件不全、文件错误造成基本功能无法实现
4.用户需求未实现
……
C类（高）---影响被测功能正确实现的问题
1.次要功能存在部分问题
2.需求理解错误
3.计算错误/取值错误等
……
D类（中）---一般性错误或者功能实现不完善等
1.界面错误(详细文档)
2.打印内容、格式错误
3.删除操作未给出提示
4.系统操作不方便
……
E类（低）---较低级错误/一些建议性的错误
1.辅助说明描述不清楚
2.错字/别字
3.可输入区域和只读区域没有明显的区分标志
4.提示窗口文字未采用行业术语
5.长时间操作未给用户进度提示
6.显示格式不规范、查询报告格式错误
7.优化/建议性的错误
……。
(完整版)BUG 等级划分标准
BUG等级划分方法一、测试BUG等级划分标准1、Blocker（崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。
如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。
2、Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。
功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。
如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。
3、Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多，合理安排解决BUG，解决率关系版本的优化程度)4、Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。
如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）二、BUG状态标准1、待处理（new）：测试人员或用户发现新问题后提交的状态2、已确认（open）：经测试人员及研发人员讨论后确认是BUG，提交的状态，由测试人员来设置。
3、已处理（fixed）：经研发人员确认是BUG后修复的状态，修改还没有验证，由开发人员来设置。
4、已修改（closed）：测试人员认为问题已经修改，通过验证，由测试人员设置。
Bug的分类标准
缺陷标示
缺陷严重等级
描述
1
严重Bug(A)
•不能执行正常工作功能或重要功能。使系统崩溃或资源严重不足。
•由于程序所引起的死机,非法退出
•死循环
•数据库发生死锁
•错误操作导致的程序中断
•严重的计算错误
•与数据库连接错误
•数据通讯错误
2
较严重Bug(B)
•严重地影响系统要求或基本功能的实现，且没有办法更正。（重新安装或重新启动该软件不属于更正办法）
•功能不符合设计要求（功能未实现、设计中没有该功能但实现了）
•程序接口错误
•数据流错误
•轻微数据计算错误
3
一般性Bug(C)
•严重地影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或•未做合理的检验出现的错误（文本型、数值型）
•打印内容、格式错误
•其它错误
•简单的输入限制未放在前台进行控制
•删除操作未给出提示
•数据输入没有边界值限定或不合理
4
较小Bug(D)
•使操作者不方便或遇到麻烦，但它不影响执行工作或功能实现。
•辅助说明描述不清楚
•显示格式不规范
•系统处理未优化
•长时间操作未给用户进度提示
•提示窗口文字未采用行业术语
5
其它Bug(E)
•客户化建议
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
BUG定义标准
广东旭普空间信息技术产业发展有限公司
2009-10-30
文档修订记录：
*说明：C――创建，A——增加，M——修改，D——删除
1引言
1.1目的
对 BUG 概念、分类、 BUG 状态、 BUG 等级划分等内容进行定义和规范，以便进一步指导我们的测试工作。
一方面也让开发人员明白各类BUG的定义，及测试人员对其程序中各类缺陷等级划分的依据。
1.2 概念
BUG ：软件中存在的瑕疵，可能会导致系统失效。
简单的说就是软件系统中存在可能导致系统出错、控制失效、死机等错误或缺陷。
1.3相关名词解释
1、软件错误：指在软件生存周期内出现的不希望或不可接受的人为错误。
2、软件缺陷：是存在于软件（文档、数据、程序）中偏离需求说明书的现象，其结果是软件运行于某一特定条件时会出现软件故障。
3、软件故障：是指软件运行过程中出现的一种不希望或不可接受的内部状态，比如：软件处于处理一个多余循环过程时，我们可以称软件出现故障，若此时没有适当的容错措施加以处理，就会导致软件失效。
4、软件失效：软件运行时产生的一种不希望或不可接受的外部行为结果。
1.4 参考资料
1、<<测试管理—bug管理>>
2、<<CMM缺陷等级划分标准>>
3、51testing软件测试专业论坛
2 BUG提交要求
1Bug通过测试组评审，属于已确认的bug
2测试人员需用清晰、简洁的文字描述bug，并能复现
3 BUG分类
1、功能错误
以需求说明书为参照，未达到或未完成需求说明书所描述的功能即为功能错误。
具体基本上可分为：
a、严重花屏
b、内存泄漏
c、用户数据丢失或破坏
d、系统崩溃/死机/冻结
e、模块无法启动或异常退出
f、严重的数值计算错误
g、重复的功能
h、多余的功能
i、遗漏的功能
j、需求未实现
k、功能设计与需求严重不符
l、其它导致无法测试的错误
2、编码错误
在系统运行中出现各类系统报错以及出现死机、不能工作、没有反应的现象即为编码错误。
包括程序接口错误、数据流错误。
3数据库错误
系统中各类查询数据、插入数据、更新数据时出现的数据库中表结构，视图、索引等不对应引起的错误。
通常还有数据库的表、业务规则、缺省值未加完整性等约束条件，导致进行添加、删除、修改、查找操作后引起的报错。
4可操作性错误
可操作性，应用方面的错误,系统操作不能连贯进行或操作步骤较复杂等。
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状态。
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 BUG严重程度
业界常规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. 流程实现不完整
5、提示信息类
A. 提示信息重复或出现时机不合理
B. 提示信息格式不符和要求
C. 提示框返回后焦点停留位置不合理
6、建议类
A. 功能性建议
B. 操作建议
C. 检校建议
D. 说明建议
7、性能类
A. 并发量
B. 数据量
C. 压缩率
D. 响应时间
8、常识类
A. 违背正常习俗习惯的，比如日期 / 节日等
9、特殊类
A. 不符合 OEM 版本或 DEMO 版本特殊要求的。