bug定义标准

BUG级别（优先级、严重级）定义⼀、主要分类BUG类型标准主要分两类：Ø 依据优先级分类。

Ø 依据严重程度分类。

⼆、主要内容依据优先级分类标准定义优先级：指⼀个BUG相对于其他BUG对于公司的影响，解决的及时性。

分类标准紧急² 系统⽆法⼯作² 测试⽆法继续正常⼯作² 特殊情况：如重要客户（项⽬重要性）⾼² 需求问题² 实现与需求不符² 出现调试代码² 功能性错误² 关联性错误² 前后模块不⼀致² 链接错误² 特殊性的程度性能低下² 程序引起的安全问题注：涉及所有关于数据流的错误中² 页⾯格式错误² 兼容性问题² 校检错误² 图⽚错误² ⽂案错误² 程序性能低下² 缺少容错性处理² 功能易⽤程度低² 配置问题注：涉及的所有关于⽂本的错误低² 遗留问题² 暂时⽆法实现技术问题² 合理建议依据严重程度分类标准定义严重程度：指⼀个BUG对于⽤户造成的影响，风险和可视性。

分类标准紧急² 程序⽆法运⾏的错误² 测试⽆法执⾏的错误⾮常⾼² 链接错误² 前后模块不⼀致² 需求问题² 实现与需求不符² 出现调试代码² 功能性错误² 程序性能低下² 程序引起的安全问题⾼² 页⾯格式错误² ⽂案错误² 图⽚错误² 兼容性错误² 校检错误中² 关联性错误² 配置问题² 功能易⽤程度低低² 合理建议² 遗留问题² 暂时⽆法实现技术问题注意事项1) ⼀些错误可以分在多个级别中，但总的标准以此为准，具体的问题具体分析后再确定其等级数。

bug优先级定义标准Bug优先级定义标准是一个用于确定和组织软件缺陷修复顺序的系统。

这个标准可以根据缺陷的严重程度、影响范围和紧急性进行评估和排序。

通过定义和遵循一套统一的标准，团队可以更好地管理和解决各种缺陷，确保关键问题得到及时解决，同时也能够更好地分配资源和时间。

一般来说，一个完善的Bug优先级定义标准应包括以下几个关键要素：1. 严重程度（Severity）：指的是缺陷对系统功能或性能的重大影响程度。

常见的严重程度分级可以是致命（Critical）、严重（Major）、一般（Minor）和轻微（Trivial）等。

这些级别通常是根据缺陷对用户体验、系统稳定性和关键功能的影响程度来定义的。

2. 优先级（Priority）：指的是修复该缺陷的紧急程度。

通常使用高、中、低等级别来表示。

优先级的确定可以考虑到缺陷对用户的影响、缺陷的复现频率、工作量以及项目进度等因素。

3. 影响范围（Impact）：指的是缺陷对系统其他功能或模块的影响程度。

评估缺陷的影响范围可以帮助团队更好地理解和评估修复该缺陷的优先级。

4. 复现频率（Reproducibility）：缺陷的复现频率可以作为评估优先级的参考因素之一。

如果一个缺陷容易被复现，可能会被赋予更高的优先级，因为它对用户和系统的影响更大。

5. 解决时限（Deadlines）：指定某些缺陷需要在特定时间内得到解决的情况。

根据项目的需求和进度，团队可以设定不同的修复时限来确定优先级。

通过以上要素的评估和综合考虑，团队可以为每个缺陷确定一个准确的优先级，从而能够更好地管理和解决系统中的问题。

举个例子，假设有一个软件中存在一个导致系统崩溃的缺陷，这个缺陷导致用户无法完成关键操作。

在这种情况下，这个缺陷在严重程度上应该被定义为致命（Critical），因为它会导致系统不可用，直接影响用户体验和业务流程。

在优先级上，这个缺陷应该被赋予高优先级，尽快解决并发布修复版本。

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，我们将其分为以下几类：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管理流程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等级/定义
等级修改完成时长验证完成时长
紧急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等级划分标准1、Blocker（崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。

如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。

2、Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。

功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。

如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。

3、Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。

如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多，合理安排解决BUG，解决率关系版本的优化程度)4、Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。

如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）二、BUG状态标准1、待处理（new）：测试人员或用户发现新问题后提交的状态2、已确认（open）：经测试人员及研发人员讨论后确认是BUG，提交的状态，由测试人员来设置。

3、已处理（fixed）：经研发人员确认是BUG后修复的状态，修改还没有验证，由开发人员来设置。

4、已修改（closed）：测试人员认为问题已经修改，通过验证，由测试人员设置。

bug单定级标准
Bug的单定级标准可以根据不同的情况和需求进行定义。

以下是一些常见的Bug定级标准：
1.致命Bug：这类Bug会导致系统崩溃、数据丢失或损坏，严重影响用户体
验或业务运行。

例如，服务端崩溃、数据库死锁等。

2.严重Bug：这类Bug会导致系统功能严重受限或异常，影响大部分用户的
使用。

例如，重要功能无法实现、操作功能异常退出等。

3.一般Bug：这类Bug对系统功能有一定影响，但不会严重影响用户体验或
业务运行。

例如，界面显示错误、部分功能使用不便等。

4.轻微Bug：这类Bug对系统功能影响较小，通常不会影响用户体验或业务
运行。

例如，小部分文字或图片错误、操作小细节上的不便等。

需要注意的是，Bug的定级标准并不是绝对的，需要根据具体情况进行判断。

同时，对于不同的项目或产品，Bug的定级标准也可能会有所不同。

软件需求与bug区分标准软件需求和bug是软件开发过程中两个不同的概念。

软件需求是指用户或系统对软件系统的功能、性能、界面等方面的要求和期望，它是软件开发的起点，包括用户需求和系统需求两个方面。

而bug是指在软件开发或使用过程中出现的错误、缺陷或故障，导致软件不能按照预期的方式工作。

首先，软件需求是指软件系统应该具备的功能、性能、界面等方面的要求，它通常由用户、业务分析师或系统分析师提出，并在软件开发过程中作为开发的基础。

软件需求应当是清晰、具体、可验证的，能够明确描述软件系统应该做什么，包括功能性需求和非功能性需求。

功能性需求指的是软件系统应该具备的具体功能，比如用户登录、数据查询等；非功能性需求则是指软件系统的性能、安全性、可靠性等方面的要求，比如响应时间、安全性要求等。

软件需求的变更通常需要经过严格的变更控制流程，以确保软件开发的方向和目标不会偏离。

而bug则是指在软件开发或使用过程中出现的错误、缺陷或故障，导致软件不能按照预期的方式工作。

bug通常是由程序代码的错误、设计缺陷、集成问题或者环境因素引起的，它会导致软件无法按照需求规格书或设计文档的要求正常工作。

在软件开发过程中，bug通常是通过测试、代码审查等方式发现的，然后需要进行修复和验证。

修复bug的过程需要严格的跟踪和管理，以确保bug得到有效的解决。

因此，软件需求和bug可以通过以下几个标准进行区分：1. 来源不同，软件需求通常由用户、业务分析师或系统分析师提出，是对软件系统功能、性能、界面等方面的要求和期望；而bug是在软件开发或使用过程中出现的错误、缺陷或故障，导致软件不能按照预期的方式工作。

2. 性质不同，软件需求是软件开发的起点，描述了软件应该做什么；bug是软件开发或使用过程中出现的问题，需要进行修复和验证。

3. 处理流程不同，软件需求的变更需要经过严格的变更控制流程；bug的修复需要严格的跟踪和管理，以确保bug得到有效的解决。

BUG定义标准广东旭普空间信息技术产业发展有限公司2009-10-30文档修订记录：版本号状态变更内容修改日期变更人V1.0 C 2009/10/28 宋洁*说明：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通过测试组评审，属于已确认的bug2测试人员需用清晰、简洁的文字描述bug，并能复现3 BUG分类1、功能错误以需求说明书为参照，未达到或未完成需求说明书所描述的功能即为功能错误。

具体基本上可分为：a、严重花屏b、内存泄漏c、用户数据丢失或破坏d、系统崩溃/死机/冻结e、模块无法启动或异常退出f、严重的数值计算错误g、重复的功能h、多余的功能i、遗漏的功能j、需求未实现k、功能设计与需求严重不符l、其它导致无法测试的错误2、编码错误在系统运行中出现各类系统报错以及出现死机、不能工作、没有反应的现象即为编码错误。

bug级别定义1级Bug（主体产品层⾯）1级bug：阻碍开发或测试⼯作的问题。

修改优先级为最⾼，该级别问题需要⽴即修改。

导致产品崩溃或不响应、设备卡死、产品程序⽆法正常安装、启动或登录等缺陷，⽤户数据受到破坏的缺陷，服务器或数据库存在安全风险，严重影响项⽬进度。

包括但不限于以下错误：1）由于程序所引起的死机2）⾮法退出死循环3）数据库发⽣死锁4）内存泄漏5）因错误操作导致的程序中断6）重⼤功能错误7）与数据库连接错误8）数据通讯错误9）系统存在安全问题，缺陷导致重要数据丢失或损坏10）功能完全违背需求要求，严重不符合产品定义等等2级Bug （主要功能层⾯）2级Bug：系统⽆法执⾏、崩溃或严重资源不⾜、应⽤模块⽆法启动或异常退出、⽆法测试、造成系统不稳定。

修改优先级为⾼，该级别需要程序员尽快修改。

主要功能完全丧失或严重错误，产品主要流程⽆法进⾏，程序导致⽤户客户端或浏览器存在安全风险，严重地影响系统要求或主要功能的实现，且没有更正办法（重新安装或重新启动该软件不属于更正办法）。

包括但不限于以下错误：1）程序接⼝错误2）因错误操作迫使程序中断3）系统可被执⾏，但操作功能⽆法执⾏（含指令）4）单项操作功能可被执⾏，但在此功能中某些功能（含指令参数的使⽤）⽆法被执⾏（对系统⾮致命的）5）在功能项的某些项⽬（选项）使⽤⽆效（对系统⾮致命的）6）业务流程不正确，或者功能操作逻辑与产品定义严重不符7）功能实现不完整，如删除时没有考虑数据关联8）功能的实现不正确，如在系统实现的界⾯上，⼀些可接受输⼊的控件点击后⽆作⽤；对数据库的操作不能正确实现9）报表格式以及打印内容错误（⾏列不完整，数据显⽰不在所对应的⾏列等导致数据显⽰结果不正确的错误）等等3级 Bug（次要功能层⾯）3级Bug：系统可以满⾜业务要求，系统性能或响应时间变慢、产⽣错误的中间结果但不影响最终结果等影响有限的问题。

修改优先级为中，该级别需要程序员修改。

BUG等级划分方法一、测试BUG等级划分标准1、Blocker（崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。

如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。

2、Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。

功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。

如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。

3、Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。

如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多，合理安排解决BUG，解决率关系版本的优化程度)4、Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。

如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）二、BUG状态标准1、待处理（new）：测试人员或用户发现新问题后提交的状态2、已确认（open）：经测试人员及研发人员讨论后确认是BUG，提交的状态，由测试人员来设置。

3、已处理（fixed）：经研发人员确认是BUG后修复的状态，修改还没有验证，由开发人员来设置。

4、已修改（closed）：测试人员认为问题已经修改，通过验证，由测试人员设置。

B U G等级划分标准 Document number：NOCG-YUNOO-BUYTT-UU986-1986UTBUG等级划分方法一、测试BUG等级划分标准1、Blocker（崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。

如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。

2、Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。

功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。

如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。

3、Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。

如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多，合理安排解决BUG，解决率关系版本的优化程度)4、Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。

如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）二、BUG状态标准1、待处理（new）：测试人员或用户发现新问题后提交的状态2、已确认（open）：经测试人员及研发人员讨论后确认是BUG，提交的状态，由测试人员来设置。

3、已处理（fixed）：经研发人员确认是BUG后修复的状态，修改还没有验证，由开发人员来设置。

BUG等级划分方法一、测试BUG等级划分标准1、Blocker（崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。

如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。

2、Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。

功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。

如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。

3、Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。

如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多，合理安排解决BUG，解决率关系版本的优化程度)4、Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。

如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）二、BUG状态标准1、待处理（new）：测试人员或用户发现新问题后提交的状态2、已确认（open）：经测试人员及研发人员讨论后确认是BUG，提交的状态，由测试人员来设置。

3、已处理（fixed）：经研发人员确认是BUG后修复的状态，修改还没有验证，由开发人员来设置。

4、已修改（closed）：测试人员认为问题已经修改，通过验证，由测试人员设置。

Bug定义规范BUG定义规范Revision History1.目的对BUG概念、BUG提交和验证、BUG状态、BUG严重程度等内容进行定义和规范，以便进一步指导我们的测试工作2.概念BUG:软件中存在的瑕疵，可能会导致软件失效。

简单的说就是软件系统中存在的可能导致系统出错、失效、死机等问题的错误或缺陷3.BUG管理工具以Quality Center 9.0为提交、跟踪等工具4.BUG提交和验证要求以QC中的字段为准提交时必选字段有：摘要，跟踪类型，检测者，检查日期，计划关闭版本，可重现，分派给，严重程度，状态，描述验证后，需要修改字段：关闭于版本，关闭日期，状态BUG描述模板如下：[问题概要]:[重现步骤]:步骤1.步骤2.[隔离分析]:[期望结果]:[重现概率]:[Test Case No.]:（若没有用例，则标注‘NA’，若是地区版本上的问题，则标注地区名称）[Test Case]:（若没有用例，则标注‘NA’，若是地区版本上的问题，则标注地区名称）QC中优先级和严重程度的区别：优先级由软件开发人员填写，严重程度由测试人员填写计划关闭版本定义：有2重含义：1.由测试人员填写当前发现bug的版本号；2.开发人员必须在此版本上修改5.BUG验证开发人员必须提供修改此bug会涉及到的功能点列表，并将此信息填写到bug描述中。

测试人员除验证此bug外，还需要将开发列出的功能点逐一验证，同时写入自己考虑到的功能点验证情况来自需求和测试自己提交的问题，测试人员都需要验证，并填写测试结果，其中来自自己的bug，若验证通过，则修改状态为“关闭”；来自需求人员的bug，则修改状态为“验证完毕”，由需求人员来关闭（适用于胜算组）。

6.BUG状态流程在正在BUG生命周期中，可能会经历很多状态，如：新建、提交验证、已关闭、重新打开、已挂起、重复提交等。

新建：新发现的问题提交验证：开发修改bug后，会将状态变为提交验证，让测试工程师来执行验证操作已关闭：测试工程师经过验证后，发现此问题已经被修复，则修改状态为已关闭重新打开：测试工程师经过验证后，发现此问题未被完全修复，则修改状态为重新打开已挂起：暂时不作修改或无法修改的bug 重复提交：开发工程师发现此bug已经有人提交过，处于重复性bug，则修改状态为重复提交验证完毕：针对来自需求的bug，需要测试人员验证，若通过，则修改其状态为验证完毕。

BUG等级划分方法一、欧阳光明（2021.03.07）二、测试BUG等级划分标准1、Blocker（崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。

如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。

2、Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。

功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。

如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。

3、Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。

如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多，合理安排解决BUG，解决率关系版本的优化程度)4、Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。

如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）三、BUG状态标准1、待处理（new）：测试人员或用户发现新问题后提交的状态2、已确认（open）：经测试人员及研发人员讨论后确认是BUG，提交的状态，由测试人员来设置。

3、已处理（fixed）：经研发人员确认是BUG后修复的状态，修改还没有验证，由开发人员来设置。

4、已修改（closed）：测试人员认为问题已经修改，通过验证，由测试人员设置。