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管理系统⼀般BUg管理⼤致流程是：1.测试⼈员提交新的Bug⼊库，错误状态为New。
2.⾼级测试⼈员验证错误，如果确认是错误，分配给相应的开发⼈员，设置状态为open。
如果不是错误，则拒绝，设置为Declined状态。
3.开发⼈员查询状态Open的Bug，如果不是错误，则置状态为Declined；如果是Bug，则修复并置状态为Fixed。
不能解决的Bug，要留下⽂字说明及保持Bug为Open状态。
对于不能解决和延期解决的Bug，不能由开发⼈员⾃⼰决定，⼀般需要通过某种会议（评审会）通过才能认可。
4.测试⼈员查询状态为Fixed的Bug，验证Bug是否已解决，如解决置Bug的状态为Closed，如没有结局置状态为Reopen。
⼀般的Bug管理系统虽然可以满⾜⽇常的Bug管理，但依然存在很多问题。
例如：功能臃肿复杂，沟通难度⼤，上⼿难度⾼，需要线下部署，安装复杂。
专业版本收费⾼昂，增⼤了企业负担等等。
以下，简单整理了⼏款Bug管理⼯具的优缺点，具体的使⽤问题还需待⼀⼀实践后整理记录。
1.QC（Quality Center）QC前⾝是TD，即TestDirector，原属于Mercury Interactive公司（被HP收购），后改名为QC。
QC是⼀个基于web的测试管理⼯具，基于J2EE(Java 2 Enterprise Edition)，可以组织和管理应⽤程序测试流程的所有阶段，包括制定测试需求、计划测试、执⾏测试和跟踪缺陷。
此外，通过Quality Center还可以创建报告和图来监控测试流程。
需要安装IIS和数据库，系统资源消耗较⼤，功能很强⼤，和其他的测试⼯具，⽐如loadrunner测试⼯具的接⼝做得⽐较好，数据可以在它们中共享。
英⽂版的易⽤性不是很好，最重要的是收费且价格不菲，破解版的费事且性能不那么稳定。
资源地址：2.BugzillaBugzilla是由Mozilla公司提供的基于web⽅式，免费的开源的⼀款强⼤的缺陷跟踪系统(Bug-Tracking System)，是专门为Unix定制开发的，有强⼤的检索功能，强⼤的后台数据库⽀持，丰富多样的配置设定等；安装需要Perl和配置MYSQL数据库，过程⽐较繁琐，修改配置⽂件⽐较⿇烦。
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分级管理制度
bug分级管理制度随着软件产品的复杂度和功能的不断增加，软件开发过程中出现Bug已经成为一种常态。
对于软件开发团队来说，如何有效地管理Bug，快速定位和解决Bug，是提高软件质量和用户体验的关键。
因此，建立一个科学有效的Bug分级管理制度至关重要。
2. 目的和意义Bug分级管理制度的目的主要包括：(1) 有效区分Bug的优先级，保证高优先级Bug得到及时处理；(2) 提高Bug解决效率，减少因为Bug而引起的软件发布延迟；(3) 帮助开发团队更好地了解软件中存在的问题，为后续版本的优化改进提供参考。
3. 制度内容Bug分级管理制度主要包括Bug的分级标准、Bug的处理流程和Bug的跟踪和反馈机制。
1) Bug的分级标准Bug的分级标准主要包括Bug的优先级和严重程度两个方面。
一般来说，Bug的优先级可以分为4个等级：紧急（Critical）、高（High）、中（Medium）和低（Low）；Bug的严重程度可以分为5个等级：致命（Fatal）、严重（Serious）、一般（Normal）、轻微（Minor）和建议（Suggestion）。
根据不同的Bug的影响范围、影响程度和解决的难易程度，将Bug分为不同的优先级和严重程度，并制定相应的处理标准。
2) Bug的处理流程Bug的处理流程包括Bug的提交、审核、跟踪、解决和验证等环节。
具体流程如下：a. Bug的提交：Bug可以由开发人员、测试人员或用户提交，需要填写Bug报告，包括Bug的描述、复现步骤、截图等信息，并指定Bug的优先级和严重程度。
b. Bug的审核：Bug报告会交由Bug管理员或项目经理审核，确认Bug是否有效。
若Bug 无效，则关闭；若Bug有效，则分配给相应的开发人员处理。
c. Bug的跟踪：开发人员接受Bug后，需要及时跟进Bug的处理进度，并更新Bug的状态和解决情况。
d. Bug的解决：开发人员需要按照Bug的优先级和严重程度，及时解决Bug，并提交代码变更。
bug管理机制
bug管理机制1. bug的概念bug，也称为软件缺陷，是在软件开发过程中出现的错误。
bug可以是代码错误、设计错误、配置错误等。
bug的存在会影响软件的正确性和稳定性，并可能导致软件崩溃、数据丢失等严重后果。
2. bug管理机制bug管理机制是指软件开发团队用来管理和修复bug的一套流程和方法。
bug管理机制通常包括以下步骤：1. bug的发现和报告bug的发现可以是开发人员在开发过程中发现的，也可以是测试人员在测试过程中发现的。
发现bug后，开发人员或测试人员需要将bug提交到bug管理系统。
2. bug的分类和优先级排序bug管理系统会根据bug的严重性、影响范围等因素，对bug进行分类和优先级排序。
3. bug的修复开发人员根据bug的优先级，对bug进行修复。
4. bug的验证开发人员修复bug后，需要对bug进行验证，以确保bug已被正确修复。
5. bug的关闭bug验证通过后，bug管理系统将bug关闭。
3. bug管理机制的重要性bug管理机制对于软件开发过程非常重要。
一个健全的bug管理机制可以帮助软件开发团队及时发现和修复bug，并减少bug对软件质量的影响。
4. bug管理机制的常见工具目前，市面上有很多bug管理工具可供软件开发团队使用。
这些工具可以帮助软件开发团队更有效地管理和修复bug。
常见的bug管理工具包括：JiraBugzillaMantisRedmineAsana5. bug管理机制的最佳实践为了提高bug管理机制的效率，软件开发团队可以遵循以下最佳实践：1. 建立清晰的bug管理流程软件开发团队需要建立清晰的bug管理流程，并确保所有团队成员都熟悉和遵守该流程。
2. 使用bug管理工具软件开发团队可以使用bug管理工具来帮助他们更有效地管理和修复bug。
3. 及时发现和报告bug软件开发团队需要及时发现和报告bug，以便开发人员能够及时修复bug。
4. 对bug进行分类和优先级排序软件开发团队需要对bug进行分类和优先级排序，以便开发人员能够优先修复最重要和最紧急的bug。
《bug处理流程》《bug处理流程》
BUG处理流程说明一、B UG处理流程图：流程描述：1、测试人员发现bug提交给开发。
2、开发人员判断是否是bug。
3、如果是bug，进行修改，修改完成后更改bug状态为已解决。
如果不是bug，退回给测试人员并描述退回原因，或为设计如此，或为外部原因，或者不能重现。
开发人员修改完成的bug，由测试人员进行验证，确认修改正确，关闭bug。
验证未通过的bug重新激活，开发人员继续修改，直至验证通过，关闭bug。
7、测试人员需要对开发人员退回的bug进行确认。
8、确认不是bug关闭。
9、如与开发人员意见不一致，认为是bug，需提交项目负责人仲裁。
10、项目负责人确认是bug由开发人员修改，不是bug由测试人员关闭。
注：除提交项目负责人仲裁环节外，其他环节都可以在禅道上完成。
二、各角色应关注的状态1.开发人员：激活、重新打开激活：开发人员要对处于激活状态的bug进行处理，处理后将其状态置成“已解决”、“设计如此”、“无法重现”、“外部原因”、“重复bug”或“延期处理”。
重新打开：重新打开的bug是已解决的bug经过测试人员验证，未修改正确，需要继续修改。
2.测试人员：已解决、无法重现、设计如此、外部原因、延期处理已解决：测试人员发现状态为“已解决”的BUG，要及时验证，如果确实已解决，要将其置为“关闭”。
否则“重新打开”无法重现：测试人员发现状态为“无法重现”的BUG，要及时修改，把步骤描述清楚，并将其状态置为“重新打开”。
设计如此：测试人员发现状态为“设计如此”和“外部原因”的BUG，要及时通知项目经理，由项目经理来决定是否修改；对“延期处理”的问题要进行定期跟踪，如发现问题没有按注释进行修改要及时通知开发人员或汇报给相关负责人。
3.项目经理：设计如此、外部原因、延期处理设计如此：因为这些BUG都是测试人员和开发人员有争议的BUG，因此项目经理必须及时关注这些BUG，及时给出合理的定夺，如果不需修改把状态置成“关闭”，如果需要立刻解决置成“重新打开”，否则置成“以后解决”。
描述缺陷管理流程
描述缺陷管理流程
缺陷管理流程主要包括以下步骤：
1. 定义缺陷：明确缺陷的标准和属性，如缺陷的严重性、影响范围等。
2. 识别和收集缺陷：通过各种手段，如测试、用户反馈等，发现和收集缺陷。
3. 验证缺陷：确认缺陷的存在和影响，并进行必要的验证。
4. 记录缺陷：将缺陷相关信息记录在缺陷管理工具中，包括缺陷的描述、严重性、影响范围等。
5. 缺陷评估：对缺陷进行优先级评估，确定修复的顺序。
6. 缺陷修复：开发人员修复缺陷，并进行必要的回归测试。
7. 回归测试：验证修复的缺陷是否已被正确修复，以及是否有引入新的问题。
8. 关闭缺陷：如果问题得到解决，关闭缺陷记录。
9. 缺陷跟踪：对缺陷进行持续跟踪，直到项目结束。
10. 总结分析：对缺陷数据进行统计和分析，以改进未来的开发和测试工作。
通过以上步骤，可以有效地管理和控制产品中的缺陷，提高产品的质量和用户体验。
BUG处理流程
BUG处理流程
1. 测试人员发现并提交一个BUG，此时BUG的状态为新建（NEW）状态，新增的BUG都提交给项目经理。
2. 项目经理确认是一个BUG后，将BUG的状态置为打开（OPEN）状态，并修改优先级，然后指定研发人员进行修复，并指定预修复时间。
3. 开发人员修改该BUG后，将BUG的状态变为已修复（FIXED），待系统BUG修复完成后，形成一个新的版本提交给测试人员。
4. 测试人员对新版本进行回归测试，如果该BUG确实已经修正，则将GUG状态修改为已关闭（CLOSDE）状态，如果仍有问题，则修改为重新打开（REOPEN）的状态，需要开发人员继续修改该项BUG。
上面是最基本也最常用的处理流程，在实际中我们还会有一些特殊情况，如：
1、如项目经理或开发人员认为测试人员提的某一个BUG不是问题，则修改状态为拒绝（REJECTED）状态，请一定加上注释说明。
2、如果有BUG开发人员采用延后处理的，开发人员在注释中要注明延后到什么时间进行处理，测试人员要进行跟踪。
3、如果项目经理不在，必须指定一位开发人员处理新增的BUG，原则上，新增BUG修改为其他状态的时间不能超过一周。
软件开发生命周期中的Bug管理研究
软件开发生命周期中的Bug管理研究第一章：概述在软件开发的过程中，操作过程和决策制定的结果都会对软件质量产生直接或间接的影响。
软件漏洞（Bug）是指在软件系统中存在的缺陷、错误或者不完整的功能。
为了确保软件系统具备高质量和可靠性，开发者需要依靠软件开发生命周期中的Bug管理来确保软件漏洞及时发现和解决。
Bug管理是软件开发与测试工作中非常重要的一个环节，它通过对软件系统的测试、审查、故障报告与解决等步骤，确保软件系统的质量和缺陷解决。
本文将探讨在软件开发生命周期中Bug 管理的重要性，并讨论各个阶段应如何进行Bug管理，以确保软件项目在质量、安全与进度上都能得到良好的保障。
第二章：Bug管理的重要性软件开发中发现和解决漏洞是至关重要的，因为漏洞可能导致安全漏洞，风险管理，工作成本和交付时间的延迟。
Bug管理是确保软件开发成功和计划顺利实施的一个有效的方法。
但是，Bug 管理不仅仅是找到和解决漏洞，它还需要可持续和全面的方法。
1. 保持软件质量和可靠性在软件开发过程中，Bug管理是一种必要的方法，可以确保开发人员在软件开发过程中发现和解决漏洞。
这种方法有助于提高软件系统的质量和可靠性。
通过Bug管理，我们可以对软件项目进行全面测试和审查，有助于认识缺陷和开发人员需要解决的问题。
这使得开发人员可以准确掌握软件系统的状态。
通过这种方式，开发人员可以了解软件开发过程中需要解决的问题类型，以及需要的资源和时间。
2. 提高软件开发效率Bug管理可以帮助开发人员在开发过程中快速解决问题。
如果没有Bug管理的方法，开发人员可能会花费更长的时间才能解决错误。
这样会导致开发时间延长，成本增加。
通过Bug管理，我们可以识别和记录错误，然后经过适当的分类和排序，使开发人员可以更快地找到导致问题的根本原因和解决方案。
这可以大大提高软件开发的效率。
3. 保护数据和保密信息在软件开发过程中，存在一些安全和隐私问题需要注意。
如果漏洞未被及时处理，那就意味着可能会存在一个或多个安全漏洞。
bug知识点总结
bug知识点总结一、Bug概念及分类1.1 Bug概念Bug是指软件或硬件中的错误、缺陷或故障。
在软件开发过程中，Bug是不可避免的，因为软件开发是一个复杂的过程，涉及到不同的环境、需求、技术等因素。
Bug的存在会影响软件的功能、性能、安全性等方面，甚至造成用户体验不佳，因此Bug的管理和修复是软件开发过程中非常重要的环节。
1.2 Bug分类根据Bug的性质和影响程度，可以将Bug分为以下几类：1) 功能性Bug：指软件功能无法正常实现或者实现不符合需求的Bug。
2) 性能Bug：指软件在性能方面存在问题，比如运行速度慢、消耗资源过多等。
3) 安全Bug：指软件存在安全漏洞或者易受攻击的Bug。
4) 兼容性Bug：指软件在不同平台、设备或浏览器上存在兼容性问题的Bug。
5) 易用性Bug：指软件的用户界面设计不佳，影响用户体验的Bug。
6) 数据Bug：指软件对数据的处理存在问题，比如数据丢失、数据错误等。
7) 遗漏Bug：指软件功能或者需求中存在遗漏的Bug。
8) 接口Bug：指软件的接口实现存在问题的Bug。
9) 界面Bug：指软件的界面显示存在问题的Bug。
10) 操作Bug：指用户在软件操作中遇到的问题的Bug。
二、Bug管理流程2.1 Bug管理流程Bug管理是软件开发过程中的一个重要环节，其流程一般包括Bug的发现、记录、分类、定位、修复、验证和关闭等阶段。
具体流程如下：1) Bug发现：软件开发人员、测试人员或用户发现软件中存在问题。
2) Bug记录：将Bug的具体信息记录下来，包括Bug的描述、复现步骤、影响程度、优先级等。
3) Bug分类：根据Bug的性质和影响程度进行分类，方便后续的处理和管理。
4) Bug定位：定位Bug产生的原因，找出Bug的根本问题。
5) Bug修复：开发人员根据Bug的定位信息进行修复工作。
6) Bug验证：测试人员对修复后的软件进行验证，确认Bug是否已经修复。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Bug的属性Bug重现环境这个应该是我们重现bug的一个前提，如果没有这个前提，我们可能会无法重现问题，或者跟本就无从下手。
操作系统这个是一般软件运行的一大前提，基本上所有的软件都依赖于操作系统之上的，对于一个软件来说，要想在某个操作系统上运行，必须要对这个操作系统支持，这就需要有真对性的设计与开发。
对于不同的操作系统，其可能存在差异（如：win xp 与win 7）或本质的区别（如win 7 与CentOS linux ），所以，操作系统环境是重现问题的一个重要前提。
浏览器对于B/S系统，或面向大众的互联网产品（网站，邮箱等），浏览器的兼容性也是必须测试的一个重点，对于现在的浏览器市场，各式的浏览器都有其用户群，要想使产品大众化，必须考虑这些产品的兼容性问题。
不同的浏览器之间（IE、firefox、chrome、opera 等），甚至同一系列不同版本（ie6/ie7/ie8/ie9等）都可能存在兼容性问题，所以，对于这类应用，浏览器环境重现bug前提条件之一。
其它（这个“其它”非常重要）对于不同的系统发现重现问题，都会有其特定的前提，拿我测试的邮箱来说，必须要描述其是在测试线还是现网环境，而且还要附带一重现问题的帐号等。
对于c/s软件，可能还要考虑与其它常用软的兼容等，例如，是在安装的某款软件后，对本软件的安装和使用造成影响。
这些都是重现问题的必须描述的环境。
问题类型根据JIRA的管理系统的划分，bug 只是问题的一种，它可以用于跟踪多种不同类型的问题（其实，他只是将bug做为一子类而已）。
JIRA系统缺省提供的问题类型（大部分的系统都可以自定义类型的，这样就增加了灵活性。
）•Bug : 测试过程、维护过程发现影响系统运行的缺陷。
（这就是一般测试人员所提交的bug）•New Feature : 对系统提出的新功能。
（单个的小需求可以，如果大的话，就相当于一个需求，放到这里是不合理的。
）•Task : 需要完成的一任务。
（开发或测试任务指派。
）•Improvement : 对现有系统功能的改进。
（一般产品经理或产品体验师做的事）当然，不同的公司，他们的人员定位与职责是不太相同的，按照上面的分类，JIRA就不是简单的缺陷管理系统了，它涵盖一项目（或产品）所需要处理的任务、需求与缺陷。
Bug 类型：这里缩小范围，单指我们测试人员在测试过程中发现的缺陷，发现产品缺陷其实就是测试人员工作的主要目的。
当然，你要确定一个问题的类型，也需要对项目（或产品）有比较深的理解。
是代码缺陷还是设计缺陷有时候就不太容易区分，当然，这个划分，对于开发定位问题影响很小，但对于问题类型的统计就比较重要了。
下面看一些常见的分类：划分方式一：代码错误设计缺陷界面优化配置相关安装部署性能问题标准规范测试代码其它划分方式二：功能类（function）性能类（performance）界面类（UI）易用性类（usability）兼容性类（compatibility）其它（else）这个分类当然是可以自定义的，具我接触的缺陷管理都是可以自定义的，既然是对问题的管理，那么你当然可以拿来做特定环境下的系统来使用，或我就想用这个系统来指派任务，那么我的自定义类型为前端任务、后端任务、测试任务、配置部署...缺陷等级缺陷等级，这个划分也比较灵活，有分三级或四级，也有分五级的。
致命一招毙命的缺陷，使你的系统无法运行，有造成数据泄漏的安全性问题。
严重可以引起易于纠正的异常情况、可能引起易于修复的故障或对产品外观难以接受的缺陷。
一般指不影响产品的运转和运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷轻微轻微缺陷是指对产品外观和下道工序可能会有轻微影响的缺陷建议增加用户使用体验的建议性问题。
（一般情况下，建议也为做为缺陷的一种。
这个跟系统的类型与需求有关）缺陷优先级（priority）当问题处理人员在面对许多问题需要处理进，就需要问题进行优先级排序。
我们做事情的安排，操作系统有处理进程等都在使用着优先级。
优先级的划分：低——>中——>高——>紧急延迟处理——>正常排队——>优先处理——>紧急处理Bug 的严重程度和优先级是含义不同但相互联系密切的两个概念，它们从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程序和处理方式。
一般地，严重程序高的软件缺陷具有较高的优先级。
严重程度高说明缺陷对软件造成的危害性大，需要优先处理，而来严重程序低的缺陷可能只是软件不太尽善尽美，可以稍后处理。
严重程度高优先级不一定高：如果某个严重的软件缺陷只在非常极端的条件下产生，则没有必要马上处理。
如果某一个软件缺陷，需要重新修改软件的整体架构，可能会产生更多的潜在缺陷，而且软件由于市场的压力必须尽快发布，此时即使缺陷的严重性很高，是否需要修正，需要全盘考虑。
严重程度优先级不一定低如果是软件名称或公司名称的拼写错误，虽然说其属于界面错误，严重程度不高，但其关系到软件和公司的市场开解，必须尽快修正。
缺陷状态对于一个问题，其处理过程是一个周期，周期的不同阶段，其所处的状态也是不一样的。
不同状态所对应的处理人也是不一样的。
打开：表示问题被提交等待有人处理。
重新指派：问题被重新指派给某人处理。
处理：问题在处理中，尚未完成。
固定：确认此问题存在，但暂时不进行处理。
回归：对已经修复的问题进行回归确认。
Reopened :关闭：问题的最后一个状态。
Bug处理流程下面通过一个比较完整的bug的处理流程图，更深刻的理解bug的状态以一个bug的生命周期。
提交（打开）缺陷在提交一个缺陷的缺陷，首先尽量描述这个缺陷的属性。
Bug重现环境，bug类型，bug等级，bug的优先级以及详细的重现步骤，结果与期望等。
当然，我们在提交一个问题之前首先应该保证，这个缺陷是没有被提过的，以免造成重复缺陷单。
如果是回归不通过的缺陷，其状态又会变为打开状态。
分配（转交）缺陷这一步不是必须的，跟项目模式有关，有些公司测试部门与开发部门独立，那么测试人员就不确定自己测试的模块是由哪位开发人员负责的，在这种情况下，测试人员统一把问题指派给项目组长或经理，由项目组长（或经理）对问题进行确认后再次分配给相应的开发人员。
有些测试人员是穿插到不同研发团队中的，所以对不同的开人发员负责的开发模块非常清楚，这个时候就可以将问题直接指派给相应的开发人员。
也有一种情况，本来此问题应该由A开发人员负责，但由于A开发人员的调离或辞职，些问题为转交给其它人员处理。
“分配”强调是上级对下级；“转交”强调的是平级之间。
确认缺陷当开发人员接到一个缺陷时，首先是对其进行分析与重现，如果对其进行分析发现不是缺陷（可能由于测试人员不了解需求）或无法对此问题进行重现，那么就需要将此问题反回给测试人员，并注明原因。
如果确认为缺陷则需要对其进行处理。
推迟处理在处理问题之后，还需要进行一次判断，是否需要推迟处理，有些需求已经确认了是问题，由于其可能在极端情况下才会出现，或需要对系统架构进行改动，或其优先级非常低，所以暂时不需要对此问题进行处理（或到下个版本进再进行修复）。
固定对于推迟处理的问题可以暂时进行固定（“固定”为QC中的叫法。
）一般固定的问题需要经过项目经理与测试经理协商后才能固定。
处理缺陷开发人员在确认完一个问题需要处理时，那么就对其进行处理工作。
（例如，redmine 是支持处理人时时更新问题处理进度的，如已处理30% ，已处理80% 等，当然，对于短时间内可以修复的问题就没必要时时的去更新处理进度。
）回归缺陷回归缺陷对于测试人员来说是非常重要的工作，其有三个入口两个出口。
确认非缺陷问题：对于提交的一个缺陷，开人员处理为非问题或无法重现，然后直接转交给测试人员回归。
测试人员再次确认，如果真如开发人员所说，则将问题关闭。
如果非开发人员所说，是由于问题描述模糊或其它原因喂重现问题，则再次注明原因转给开发人员。
确认修复问题：对开发人员修复的问题再次进行确认，确认能过，则关闭问题。
确认不通过，将问题再次打开并转给开发人员。
确认固定问题：有计划的对固定问题进行确认，有些固定问题随着时间的推移，版本的更新或已经不存在了，对这类问题应该及时关闭。
有些固定问题依然存在且变得紧急，对于这类问题应该及时打开交给开发人员处理。
关闭缺陷对于已经修复的缺陷进行关闭，这也是一个缺陷的最后一个状态。
注1：文中提到了产品与项目，好多人分不清项目与产品，各自有各自的理解。
我个人从用户群上来划分。
如果面向的是特定客户的需求，那么称其为项目，如某医院的医疗系统，某公司的管理系统。
面向大众用户且长期运营的需求，称为产品，如，某网站，某网络游戏。
如果小A让我给他做一个网站呢？对于我来说，小A是我的客户，这个网站对我来说就是一个项目，对于小A来说，他的网站是面向大众用户的，那么对于小A来说，网站就是自己的产品。
富士康带工苹果手机是一样的道理，富士康接到苹果的订单，那么对富士康来说是个项目，完成项目，拿到钱就算项目结束。
苹果手机对苹果公司来说是一个产品，它长期持有这个产品的所有权，并且不段的更新自己的产品。
注2：本文中用到了bug、缺陷、问题等三个词语，用词比较模糊，本文中表示为一个事物。