bug状态

Bug的状态管理与跟踪

Bug的状态管理与跟踪Bug是指在软件开发或使用过程中出现的错误或问题。

为了有效地解决Bug并提高软件质量，需要对Bug进行状态管理与跟踪。

本文将探讨Bug的状态管理及跟踪的重要性，并介绍一些常用的Bug跟踪工具和流程。

一、Bug状态管理的重要性Bug的状态管理是指对Bug在不同阶段的处理过程进行管理和记录。

一个良好的Bug状态管理系统能够帮助开发团队更好地追踪和处理Bug，提高开发效率和软件质量。

1. 提高Bug跟踪效率：通过对Bug进行分类和标记，可以快速找到并解决Bug，减少团队在排查和修复Bug上的时间和精力消耗。

2. 加强沟通与协作：Bug状态管理系统可以提供实时的Bug状态信息，开发人员、测试人员和产品经理可以更好地进行沟通和协作，推动Bug处理的进展。

3. 增强Bug管理能力：通过对Bug的状态和处理过程进行跟踪，可以及时发现和解决软件中的潜在问题，提高软件的稳定性和可靠性。

二、Bug状态管理与跟踪的常用流程Bug状态管理与跟踪通常包括以下几个关键步骤：1. Bug的创建：当发现Bug时，测试人员应该及时在Bug跟踪系统中创建一个新的Bug报告。

Bug报告应包含详细的Bug描述、复现步骤和相关的附件等信息。

2. Bug的分配：在Bug跟踪系统中，应根据Bug的严重程度和优先级，将Bug分配给相应的开发人员进行处理。

同时，可以通过设置通知机制，让相关人员及时得到Bug分配的通知。

3. Bug的确认和处理：开发人员收到Bug后，应尽快确认Bug并进行处理。

在处理过程中，可以将Bug的状态设置为“已修复”、“待验证”等。

开发人员应在处理完成后进行代码提交，并在Bug跟踪系统中更新Bug的状态和处理进度。

4. Bug的验证和关闭：在开发人员修复Bug后，测试人员需要对Bug进行验证。

验证通过后，可以将Bug的状态设置为“已关闭”，表示Bug已经得到有效解决。

5. Bug的回归和再测试：在软件版本更新或重大修改后，应对之前已关闭的Bug进行回归测试。

Bug状态流程

Bug 状态流程
-Yang
Bug状态流程图 Bug状态流程图
Bug 处理流程
开发组长/ 开发组长/经理每天对Bug进行分配，标注处理意见，给定优先级（发版前必须三方：需求、开发、产每天对Bug进行分配，标注处理意见，给定优先级（发版前必须三方：需求、开发、产品共同确定）。问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是留给开发人员。有可能是需求的问题，分配给需求人员。定期对Bug库分析，找出常出留给开发人员。有可能是需求的问题，分配给需求人员。定期对Bug库分析，找出常出错的模块，进行代码审查。开发人员分析Bug，写出问题原因，修改Bug；实行Bug优先原则，严重程度B Major类或紧急程度分析Bug，写出问题原因，修改Bug；实行Bug优先原则，严重程度B-Major类或紧急程度 3-High类以上（包含）bug5个或5个以上，停止新功能的开发。 High类以上（包含）bug5个或5 需求人员解释需求，给出处理意见，将Bug库中的建议整理成需求文档。评审确定后列入开发计解释需求，给出处理意见，将Bug库中的建议整理成需求文档。评审确定后列入开发计划测试人员不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度。验证Bug是否已被解不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度。验证Bug是否已被解测试组长/ 测试组长/经理审核测试人员提交的Bug。定期对Bug库进行分析，描绘出曲线图等，报告现状、预测审核测试人员提交的Bug。定期对Bug库进行分析，描绘出曲线图等，报告现状、预测趋势。在测试总结报告中给出意见产品人员可以对优先级和处理意见等进行审核，如果有意见，和项目组商量定夺
新Bug 复测时新出现的Bug 偶发性原来修改过的问题又重新出现需求要求但没有做的功能需求需要完善与需求不一致设计要求但没有做的功能

BUG等级划分标准

B U G等级划分方法一、测试BUG等级划分标准1、Blocker崩溃：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环,导致数据库数据丢失,与数据库连接错误,主要功能丧失,基本模块缺失等问题;如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等该问题在测试中较少出现,一旦出现应立即中止当前版本测试;2、Critical严重：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失,一级功能菜单不能使用但是不影响其他功能的测试;功能设计与需求严重不符,模块无法启动或调用,程序重启、自动退出,关联程序间调用冲突,安全问题、稳定性等;如：软件中数据保存后数据库中显示错误,用户所要求的功能缺失,程序接口错误,数值计算统计错误等该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试;3、Major一般：功能没有完全实现但是不影响使用,功能菜单存在缺陷但不会影响系统稳定性;如：操作时间长、查询时间长、格式错误、边界条件错误,删除没有确认框、数据库表中字段过多等该问题实际测试中存在最多,合理安排解决BUG,解决率关系版本的优化程度4、Minor次要：界面、性能缺陷,建议类问题,不影响操作功能的执行,可以优化性能的方案等;如：错别字、界面格式不规范,页面显示重叠、不该显示的要隐藏,描述不清楚,提示语丢失,文字排列不整齐,光标位置不正确,用户体验感受不好,可以优化性能的方案等此类问题在测试初期较多,优先程度较低；在测试后期出现较少,应及时处理二、BUG状态标准1、待处理new：测试人员或用户发现新问题后提交的状态2、已确认open：经测试人员及研发人员讨论后确认是BUG,提交的状态,由测试人员来设置;3、已处理fixed：经研发人员确认是BUG后修复的状态,修改还没有验证,由开发人员来设置;4、已修改closed：测试人员认为问题已经修改,通过验证,由测试人员设置;5、仍存在reopened：测试人员认为BUG未修复成功,问题仍然存在,由测试人员设置;6、不是问题reject：研发人员确认不是BUG,或者建议与意见决定不采纳;7、暂不处理hold：当前版本不做修改,后续版本再考虑,由研发人员或测试人员设置;三、BUG处理流程1、紧急：崩溃、严重BUG处理流程1-2天内解决2、优先：一般BUG处理流程尽快处理3、普通：次要BUG处理流程项目结束前处理。

Bug的状态管理

Bug的状态管理Bug是软件开发过程中难免出现的问题，它们可能会导致软件在使用过程中出现异常或功能不完善。

为了有效地跟踪和解决Bug，我们需要进行Bug的状态管理。

本文将介绍Bug的状态管理流程以及常见的Bug状态。

一、Bug状态管理流程1. 提交Bug：当用户或测试人员在软件中发现Bug时，需要将Bug提交给开发团队。

通常，会在Bug管理系统中填写Bug报告，记录Bug的详细信息，包括描述、复现步骤、截图等。

2. 确认Bug：开发团队接收到Bug报告后，会对Bug进行确认。

他们会根据报告中提供的信息，尝试复现Bug并验证其正确性。

如果确认Bug存在，将进入下一步处理。

3. 分配Bug：确认Bug存在后，开发团队会将Bug分配给相应的开发人员进行修复。

通常，开发人员会根据Bug的严重程度和优先级进行分配。

严重程度指Bug对软件功能、性能或用户体验的影响程度，而优先级指Bug在修复顺序上的紧急程度。

4. 修复Bug：开发人员接收到Bug后，会开始进行Bug的修复工作。

他们会根据Bug报告中提供的信息，定位并解决Bug导致的问题。

5. 验证Bug修复：在Bug修复完成后，开发人员会进行Bug修复的验证。

他们会重新按照报告中提供的复现步骤，验证Bug修复是否有效，并确保软件功能正常。

6. 关闭Bug：如果验证Bug修复成功，开发人员会将Bug状态设置为已关闭。

同时，会将修复的版本信息记录在Bug报告中，以便日后跟踪。

二、常见的Bug状态1. 新建：表示Bug刚被提交，尚未被确认或分配。

2. 确认：表示Bug已被开发团队确认存在，但尚未分配给开发人员。

3. 分配：表示Bug已被分配给具体的开发人员，等待开发人员处理。

4. 修复中：表示开发人员正在处理Bug修复工作。

5. 待验证：表示Bug修复已完成，等待开发人员进行验证。

6. 重新打开：如果验证Bug修复失败或发现新的问题，开发团队会重新打开Bug，并进入修复流程。

TD使用简易说明

1.2.BUG状态说明状态“new”，表示该BUG已建立但是没有打开，没有生效，开发员可以不处理状态“open”表示该BUG已经打开并生效，开发员必须处理状态“fixed”表示该BUG已经被修复，测试员可以进行测试状态“reopen”表示该BUG虽然已修复，但是仍然存在问题状态“rejected”表示该BUG无效，被拒绝修复状态“closed”表示该BUG已成功修复状态“Duplicate”表示该BUG重复状态“Postponed”表示该BUG需要延期BUG状态图：1.3.建立并提交BUG适用对象：测试员第一步：登陆TD图1.登陆界面图2.登陆成功后页面说明：图中标识的1是用来设置显示的列图中标识的2是用来新增bug的图3：登录陆后可以修改密码第二步：记录BUG 图1.添加BUG界面1.3.1.工具栏使用使用最多的就是添加截图与添加URL添加截图方式1.添加本地图片，点击图标添加截图方式2.使用TD自带截图工具，点击图标，拖动弹出界面上的相机图标到你想要接的图片上即可，这种方式不是很好用添加URL：点击图标，弹出URL输入框，图2图21.3.2.信息栏使用这里主要是录入BUG的相关信息BUG主题：简单描述BUGBUG记录人：登陆进来后默认是当前登陆人，可选择BUG记录时间：登陆进来默认当前时间，可选择严重程度：优先级：1.3.3.附件栏使用这里主要是显示添加的附件，如图片、URL1.3.4.BUG描述栏使用这里主要用于描述BUG的详细内容主要是记录：环境、登录用户、菜单路径、预置条件、操作步骤、预期结果、测试结果。

1.3.5.BUG提交录入完BUG信息后，点击提交，测试员新建并提交的BUG，对应状态是”new”需要项目经理确认并将BUG状态修改为“open”该BUG才算生效1.4.指派BUG适用对象：项目组长、经理对BUG的状态、处理人、处理时间进行修改只处理“new”状态的BUG，对无效BUG可以进行“Rejected”拒绝修复操作，对暂时无法修复的bug进行“postponed”，延期修复操作。

Bug管理Bug的3种状态状态说明Active（活动）Bug的初始状态。任何

BUG 生命周期新建的Bug处于Active状态，可以通过编辑指派给合适的解决者。

解决Bug之后，Bug状态变为Resolved，并自动指派给创建者。

创建者验证Bug。

如果未修复，再重新激活，Bug状态重新变为Active；如果已经修复则可以关闭，Bug状态变为Closed，Bug生命周期结束。

已经Closed的Bug如果重新复现，也可以直接激活。

具体流程如下图所示。

BUG 字段说明Bug 标题：为包含关键词的简单问题摘要，要有利于其他人员进行搜索或通过标题快速了解问题项目名/模块路径：指定问题出现在哪个项目的哪个模块。

Bug处理过程中，需要随时根据需要修改项目或模块，方便跟踪。

如果后台管理指定了模块负责人，选择模块时，会自动指派给负责人指派给：Bug的当前处理人。

如果不知道Bug的处理人，可以指派给Active，项目或模块负责人再重新分发、指派给具体人员。

如果设定了邮件通知，被指派者会收到邮件通知。

此外，状态为Closed的Bug，默认会指派给Closed，表示Bug生命周期的结束抄送给：需要通知相关人员时填写，例如测试主管或者开发主管等。

可以同时指派多个，人员之间用逗号分隔。

如果设定了邮件通知，当Bug有任何更新时，被指派者会收到邮件通知严重程度：Bug的严重程度。

由Bug的创建者视情况来指定。

1为最严重的问题，4为最小的问题。

一般来讲，1级为系统崩溃或者数据丢失的问题；2级为主要功能的问题；3级为次要功能的问题；4级为细微的问题优先级：Bug处理的优先级。

一般由Bug的解决人员按照资源和项目的进度指定。

1的优先级最高，需要尽快处理，4的优先级最低其余选项字段（Bug类型、如何发现、操作系统、浏览器）：可以通过编辑Lang/ZH_CN_UTF-8/_COMMON.php来自定义创建Build：Bug是在哪个版本（Build或者Tag）被发现的解决Build：Bug是在哪个版本（Build或者Tag）被解决的解决方案：参考Bug的7中解决方案。

New（新bug）：一般测试人员录入一个新bug时，这个就是第一个默认初始状态，而开发人员看到这个状态时bug,就知道这是一个新引入的bug。见到这个状态表示该bug必须被处理。
Assigned（已指派的）：当一个buAssigned”。
Invalid（不是bug）：被描述的问题不是一个bug（测试人员提出这个bug,但是开发人员认为不是bug）。
Wontfix（不修改bug,NeedlessFix）：被描述的问题是一个bug,但是不准备进行修改。
Later（下一版本再修改）：被描述的问题是一个bug,但是不在当前版本中进行修改。（已经确定在下一版本修改）
Reopen(重新打开)：开发人员FIXED之后，但是经过测试他的这个bug仍然没有被解决（如果这个bug解决掉，引入的新bug不在此列）。
Close（关闭bug）：bug已经被解决,解决方案是被认为是正确的（这一步表示bug修复过程已经完成）。
Fixed（已解决）：bug已经被解决,并且通过经过测试。
Remind（可能到下一个版本再修改）：被描述的问题是一个bug,但是很可能不在目前版本中进行修改（注意是可能，注意later）
Duplicate（bug重复）：提出的问题和当前已经存在的某个bug重复。
Worksforme（bug不能重现）：不能重现这个bug,查看源代码也不知道为什么会出现这样的bug 现象,如果以后有更多的关于这个bug的线索,将重新接受这个bug。（这个是对于那些知道有bug，但是却不能重现bug的情况）

bug管理的简单流程

Bug管理的简单流程：BUG的各种状态：◆新错误(New)：测试中新报告的软件缺陷。

◆打开 (Open)：错误被确认并分配给相关开发人员处理。

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

◆拒绝(Rejected)：拒绝修改缺陷。

包括两种情况：拒绝-不是错误（Rejected-Not Bug）：报告的错误不是错误。

拒绝-重复（Rejected-Duplicated）：以前已经报告过这个错误，需要指出已经报告过的错误ID编号。

◆重新打开（Reopen）：没有正确修复的错误，需要进一步修复。

◆延期修改(Deferred)：不在当前版本修复的错误，以后的版本修复。

◆不能重现(Reproduct):开发人员在自己的环境下不能重现的缺陷。

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

BUG管理的基本流程：1、测试人员提交新的Bug入库，此时BUG状态为New。

2、错误被确认，项目经理将Bug分配给相应的开发人员，设置Bug状态为Open,与此同时，测试人员和开发人员同时收到改变Bug状态的邮件。

特殊时候若测试人员非常了解Bug所属，测试人员也可直接分配Bug给开发人员，并设置置Bug状态。

3、开发人员查询状态为Open和Reopen的Bug，若Bug反映的问题是由于开发平台本身的缺陷或是测试人员操作错误引起时，置Bug状态为Rejected；4、当Bug反映的内容不包含在当前需求规格说明中，属于升级或者优化功能,且该Bug的存在不影响客户操作的顺利进行,开发人员可以延迟修复时间，置Bug的状态为Deferred；是Bug则解决并置状态为Fixed，Rejected和Deferred的Bug，开发人员要留下文字说明。

5、测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。

Bug的状态每改变一次，都会邮件周知相关的人员，让其明确Bug的当前状态。

BUG统计与质量控制

BUG统计与质量控制一、引言在软件开发过程中，不可避免地会出现各种各样的BUG（缺陷）。

对于一个软件项目来说，及时发现和解决这些BUG是非常重要的，以确保软件的质量和稳定性。

本文将介绍BUG统计与质量控制的标准格式文本，详细描述了BUG统计与质量控制的相关内容和数据。

二、BUG统计1. BUG分类根据严重程度和影响范围，将BUG分为以下几个分类：- 严重：对软件的功能和性能产生严重影响，导致软件无法正常运行或崩溃。

- 一般：对软件的功能和性能产生一定影响，但不会导致软件无法正常运行。

- 轻微：对软件的功能和性能产生轻微影响，不会对软件的正常运行造成明显影响。

2. BUG状态根据BUG的处理进度，将BUG分为以下几个状态：- 新建：当发现一个BUG时，将其状态设置为新建。

- 待处理：BUG被分配给开发人员进行处理，状态设置为待处理。

- 处理中：开发人员正在处理BUG，状态设置为处理中。

- 待验证：开发人员修复BUG并提交代码后，将其状态设置为待验证。

- 验证通过：测试人员验证BUG已被修复并通过，状态设置为验证通过。

- 验证失败：测试人员验证BUG未被修复或修复不完全，状态设置为验证失败。

- 关闭：BUG已被修复并验证通过，状态设置为关闭。

3. BUG统计报告BUG统计报告是对BUG进行统计和分析的文档，包括以下内容：- 项目名称：所属项目的名称。

- 统计周期：统计的时间范围。

- 总BUG数：统计周期内发现的总BUG数量。

- 严重BUG数：统计周期内发现的严重BUG数量。

- 一般BUG数：统计周期内发现的一般BUG数量。

- 轻微BUG数：统计周期内发现的轻微BUG数量。

- 待处理BUG数：统计周期结束时待处理的BUG数量。

- 处理中BUG数：统计周期结束时处理中的BUG数量。

- 待验证BUG数：统计周期结束时待验证的BUG数量。

- 验证通过BUG数：统计周期内验证通过的BUG数量。

- 验证失败BUG数：统计周期内验证失败的BUG数量。

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

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

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

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

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

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

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

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

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

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

BUG等级划分标准

B U G等级划分标准(总3页) -CAL-FENGHAI.-(YICAI)-Company One1-CAL-本页仅作为文档封面，使用请直接删除BUG等级划分方法一、测试BUG等级划分标准1、Blocker（崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。

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

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

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

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

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

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

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

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

列出bug的几种状态

列出bug的⼏种状态
1、New:（新的）
当某个“bug”被发现的时候（），测试⼈员需要与项⽬负责⼈沟通以确认发现的的确是⼀个bug，如果被确认是⼀个bug，就将其记录下来，并将bug的状态设为New。

2、Assigned（已指派的）
当⼀个bug被指认为New之后，将其将给开发⼈员，开发⼈员将确认这是否是⼀个bug，如果是，开发组的负责⼈就将这个bug指定给某位开发⼈员处理，并将bug的状态设定为“Assigned”。

3、Open（打开的）
⼀旦开发⼈员开始处理bug的时候，他（她）就将这个bug的状态设置为“Open”，这表⽰开发⼈员正在处理这个“bug”。

4、Fixed（已修复的）
当开发⼈员进⾏处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责⼈，然后开发组的负责⼈将这个bug返还给测试组。

5、Pending Reset（待在测试的）
当bug被返还到测试组后，我们将bug的状态设置为“Pending Reset”。

6、Reset（再测试）
测试组的负责⼈将bug指定给某位测试⼈员进⾏再测试，并将bug的状态设置为“Reset”。

BUG等级划分标准

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

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

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

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

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

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

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

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

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

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

BUG等级划分标准

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

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

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

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

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

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

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

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

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

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