测试中的BUG管理
如何处理测试过程中的Bug
如何处理测试过程中的Bug在软件开发过程中，测试是必不可少的环节。
其中，Bug是测试过程中经常出现的问题，也是需要尽快解决的重要任务。
本文将介绍如何高效地处理测试过程中的Bug，并提供一些实用的技巧和建议。
一、快速定位Bug在测试过程中，快速定位Bug是非常关键的一步。
以下是一些方法和技巧：1.复现Bug：在进行Bug定位前，首先要能够复现Bug。
通过重复操作的方式，确定Bug的出现条件和步骤，有助于准确定位问题。
2.查看日志：日志记录了软件运行过程中的详细信息，往往可以提供有价值的线索。
仔细阅读和分析日志文件，有助于找到Bug所在。
3.使用调试工具：调试工具可以帮助开发人员深入代码，追踪程序执行过程中的变量和状态，有助于定位Bug。
4.收集异常信息：当软件出现异常时，要及时收集异常信息，包括错误代码、堆栈跟踪等，这些信息有助于分析问题原因。
二、准确描述并提交Bug报告准确描述和提交Bug报告对于问题的解决至关重要。
以下是一些建议：1.提供详细的步骤：在Bug报告中，详细描述出现问题的具体步骤，并附上截图或录屏，以便开发人员能够复现和分析Bug。
2.明确Bug的表现：准确描述Bug的表现形式，包括错误提示、异常行为等。
这有助于开发人员快速定位问题。
3.注明Bug优先级和影响范围：对于Bug的优先级和影响范围进行明确标注，有助于开发人员针对不同严重程度的Bug进行合理分配和解决。
4.附上测试环境信息：提供测试环境的相关信息，如操作系统版本、软件配置等，有助于开发人员复现和定位问题。
三、与开发团队密切合作处理Bug需要与开发团队密切合作，加强沟通和协同。
以下是一些建议：1.建立Bug跟踪系统：使用Bug跟踪系统，对Bug进行记录、跟踪和管理，便于开发人员和测试人员的协同工作。
2.及时反馈Bug进展：开发人员在解决Bug过程中，及时更新Bug状态和进展，让测试人员了解问题的解决情况。
3.开展Bug讨论会：定期开展Bug讨论会，邀请测试人员和开发人员一同参与，共同分析和解决Bug。
BUG管理规范与流程
实用标准文档BUG管理流程与规范目录1概述 (4)1.1编写目的 (4)1.2适用范围 (4)2关键角色及应负责任 (4)3BUG流程图 (5)4活动描述 (5)5BUG书写规范 (7)5.1测试人员BUG提交 (7)5.1.1主题 (7)5.1.2步骤 (7)5.1.3实际结果 (7)5.1.4预期结果 (7)5.1.5备注 (8)5.2开发人员解决BUG (8)6BUG严重等级 (9)6.1致命 (9)6.2严重 (9)6.3一般 (10)6.4优化 (10)7BUG优先级 (10)7.1紧急 (10)7.2高 (11)7.3中 (11)7.4低 (11)8BUG解决方案 (11)8.1设计如此 (11)8.2重复BUG (11)8.3已解决 (11)8.4无法重现 (11)8.5延期处理 (11)8.6新增/变更需求 (11)9BUG状态 (11)9.1激活 (11)9.2已解决 (11)9.3关闭 (11)10其他要求 (12)11相关文件 (12)12附件 (12)1概述1.1编写目的本文档定义bug的整个生命周期，规范bug的管理流程。
Bug在流转的过程中有章可循。
规范bug严重等级与bug解决优先级，使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决。
1.2适用范围本文档适用测试人员、开发人员。
2关键角色及应负责任5BUG书写规范5.1测试人员BUG提交5.1.1主题•用一个简短的句子描述问题，不要写成一大段•以进入问题模块路径开头，方便项目经理分派任务，以及开发人员定位问题•描述问题时要详细、简练、抓住要点，直接切入正题，不要罗嗦•不要夸大或缩小问题的严重程度5.1.2步骤•用数字编号，一步步的描述重现问题的所有操作步骤•提供明确的再现问题的步骤，避免问题被以“不能重现”关掉•设置区域需要详细描述，如：各设置项值为默认、**值更改为“”，其他设置项值为默认；•尽量用动词作为开头，描述每个步骤。
软件测试中的Bug管理与缺陷追踪
软件测试中的Bug管理与缺陷追踪在软件开发过程中，无论是小型项目还是大型项目，都难免会出现各种Bug和缺陷。
为了保证软件的质量和稳定性，Bug管理与缺陷追踪成为了非常重要的环节。
本文将着重介绍软件测试中的Bug管理与缺陷追踪的流程和方法。
一、Bug管理的流程1. Bug的发现与记录Bug的发现可以通过测试用例的执行、用户反馈、团队成员的发现等多种途径。
一旦发现Bug，测试人员应该及时记录下来，并详细描述Bug的现象、触发条件、影响范围等相关信息。
2. Bug的分类与优先级评定为了更好地管理和解决Bug，需要对Bug进行分类和优先级评定。
常见的分类包括功能性Bug、性能缺陷、界面缺陷等。
而优先级评定则是根据Bug的影响程度和紧急程度划分Bug的等级，以确定解决Bug的优先顺序。
3. Bug的分配和解决根据Bug的分类和优先级，测试团队将Bug分配给相应的开发人员进行解决。
开发人员需要仔细阅读Bug的描述和重现步骤，进行代码调试和修改，修复Bug并提交相应的版本。
4. Bug的验证和关闭修复Bug后，测试团队需要重新执行相关的测试用例，验证Bug是否被成功修复。
如果Bug被成功修复，则将其关闭；如果Bug未被修复或者修复不完全，则重新分配给开发人员，并重复上述过程，直至Bug得到完全修复和验证通过。
二、缺陷追踪的方法1. 缺陷管理工具为了更好地管理和追踪缺陷，可以使用专门的缺陷管理工具。
这些工具可以帮助团队快速记录、追踪、查询和统计Bug信息，提高Bug 管理的效率和准确性。
常见的缺陷管理工具有JIRA、Bugzilla、Redmine等。
2. 缺陷报告对于发现的缺陷，测试人员需要准备详细的缺陷报告。
缺陷报告应包括缺陷的描述、重现步骤、系统环境、日志信息等，并尽量附带相关的截图或录屏。
通过准确、清晰的缺陷报告，可以提高开发人员理解和解决缺陷的效率。
3. 缺陷追踪矩阵缺陷追踪矩阵是一种通过矩阵方式来记录和追踪缺陷的方法。
软件测试中常见的Bug修复技巧
软件测试中常见的Bug修复技巧在软件开发过程中，无论我们多么努力地编写高质量的代码和进行全面的测试，Bug仍然可能会出现。
这些Bug可能是由于误解需求、错误的实现、或者其他未曾预料到的原因导致的。
为了保证软件的可靠性和稳定性，在发现Bug之后，我们需要及时修复它们。
下面将介绍一些常见的Bug修复技巧，帮助我们更高效地解决Bug。
1. 理解Bug报告：在修复Bug之前，我们首先需要仔细阅读Bug报告，了解Bug的复现步骤和预期结果以及实际结果的差异。
这有助于我们更好地理解Bug所在的问题，从而找到更合适的修复方法。
2. 重现Bug：为了更好地理解Bug并确保修复效果，我们需要尽可能地重现Bug。
通过重现Bug，我们可以更加深入地分析问题的根本原因，从而有针对性地进行修复。
3. 分析代码：一旦我们理解Bug所在的问题，并且已经成功地重现了它，我们需要对相关代码进行仔细分析。
我们可以通过调试工具、日志记录、代码审查等手段来查找潜在问题，并找到可能导致Bug的原因。
4. 修复Bug：一旦我们找到了Bug的原因，我们可以采取以下一些常见的修复方法：a. 代码修正：对于一些简单的Bug，我们可以直接修改代码中出现问题的地方。
确保在修改代码的同时，不会对其他的功能产生负面影响，所以要牢记修改代码的同时需要及时进行单元测试和回归测试。
b. 重构代码：对于一些复杂的Bug，我们可以考虑对相关代码进行重构。
通过重新设计代码结构和逻辑，我们可以消除潜在的Bug，并提高代码的可维护性和可测试性。
c. 引入单元测试：在修复Bug的同时，我们还可以引入单元测试用例。
通过编写相关的单元测试，可以确保修复的Bug得到持久性的解决，并能及时发现后续可能引入的新Bug。
d. 使用工具辅助：在修复Bug的过程中，我们可以使用一些调试和分析工具来辅助定位和解决问题。
例如，使用静态分析工具进行代码扫描，或者使用运行时分析工具来监控程序的行为。
测试过程中遇到了不能复现的bug的时候你该怎么办
测试过程中遇到了不能复现的bug的时候你该怎么办
偶然性问题的处理
在测试执⾏过程中，⼀旦系统出现异常信息，我们第⼀时间要做的是截图，保存证据；
确定是偶然性的bug之后，收集相关的⽇志，连同截图⼀并提交过单位开发
如果缺陷在当前版本⽆法复现，且缺陷的影响程度⽐较低，我们会跟踪三个版本，如果后三个版本都⽆法复现，就可以关闭该缺陷；
如果很严重的Bug,除了要及时反馈给上级之外，最后还要写到测试报考中，说明出现了什么现象，但⽆法再现！
详细记录预期与实际的不⼀致，如果不⼀致，要从多个⾓度多测试⼏次，尽量详细的定位软件出错的位置和原因，并测试出因为这个错误会不会导致更严重的错误出现，最后把详细的输⼊和实际的输⼊，以及对问题的描述写到测试报告中。
因为在⼀个项⽬组中，项⽬的开发时间是有效的，如果我们测试时能把问题描述详细⼀些，那么开发⼈员就会很容易的重修这个问题，也就能更快的解决问题，节省项⽬时间。
提交缺陷时与开发的关系处理
坚持原则
对事不对⼈，拿证据说话
尊重对⽅的劳动成果，平时和开发⼈员打好关系，不要把关系搞僵。
游戏开发公司测试人员Bug反馈管理制度
游戏开发公司测试人员Bug反馈管理制度在游戏开发过程中，测试人员是至关重要的一环。
他们的主要任务是发现并记录游戏中的错误，也被称为“Bug”。
然而，仅仅发现错误是不够的，测试人员还需要及时而准确地将这些问题反馈给开发团队，以便进行修复。
为了有效管理测试人员的Bug反馈，游戏开发公司需要建立一个完善的管理制度。
一、Bug反馈流程1. 测试人员发现Bug后，应在一个统一的Bug反馈平台进行记录。
该平台可以是公司内部开发的系统，也可以是现有的第三方工具。
无论选择何种方式，都应保证记录Bug的方便性和准确性。
2. 在Bug反馈平台中，测试人员需要提供详细的Bug描述，包括出现Bug的具体步骤、错误提示、截图或录像等有助于问题定位的信息。
3. 每个Bug都应有一个唯一的标识符，用于跟踪和定位问题。
可以使用系统自动生成的Bug ID，也可以根据公司规定的方式进行命名。
4. 在Bug反馈时，测试人员应将问题所属的模块、关键影响因素、严重程度等相关信息进行填写，以便开发人员能够更好地理解问题的重要性和紧急程度。
二、Bug反馈的优先级和处理时间1. 根据测试人员的Bug反馈，开发团队应对其进行优先级的评估。
通常情况下，Bug的优先级可以分为高、中、低三个级别，以便开发人员在修复问题时有针对性地安排时间和资源。
2. 高优先级的Bug应尽快处理，通常要求在24小时内进行回应或修复。
这些Bug可能导致游戏崩溃、重要功能无法正常运行或对玩家造成严重影响。
3. 中优先级的Bug应在3个工作日内进行回应或修复。
这些Bug可能会影响游戏的流畅性或功能完整性，但并不会对玩家产生重大负面影响。
4. 低优先级的Bug可以在较长时间内进行修复，一般要求在5个工作日内回应或修复。
这些Bug主要是一些细节问题，对游戏整体体验影响较小。
5. 如果游戏中存在无法在短期内修复的问题，开发团队应给予测试人员明确的解释，并在Bug反馈平台上进行及时更新，以便让所有相关人员了解问题的处理进度。
bug等级划分标准
6. 测试bug等级划分标准：
按照jira管理工具上，bug主要分五类：
1）Blocker：阻碍开发或测试工作的问题。
（这个测试人员通常很少遇到）
2）Critical：系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。
具体基本上可分为：
○严重花屏
○内存泄漏
○用户数据丢失或破坏
○系统崩溃/死机/冻结
○模块无法启动或异常退出
○严重的数值计算错误
○功能设计与需求严重不符
○用户权限问题
○安全问题
○其它导致无法测试的错误
3）Major：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性
具体基本上可分为：
○功能未实现
○功能错误
○系统刷新错误
○语音或数据通讯错误
○轻微的数值计算错误
○系统所提供的功能或服务受明显的影响
4）Minor：界面、性能缺陷
具体基本上可分为：
○操作界面错误（包括数据窗口内列名定义、含义是否一致）
○边界条件下错误
○提示信息错误（包括未给出信息、信息提示错误等）
○长时间操作无进度提示
○系统未优化（性能问题）
○光标跳转设置不好，鼠标（光标）定位错误
5）Trivial：易用性及建议性问题
具体基本上可分为：
○界面格式等不规范
○辅助说明描述不清楚
○操作时未给用户提示
○可输入区域和只读区域没有明显的区分标志
○个别不影响产品理解的错别字
○文字排列不整齐等一些小问题
○建议。
BUG管理规范
BUG管理规范一、背景介绍在软件开辟过程中，由于各种原因，可能会浮现各种各样的错误或者缺陷，这些错误或者缺陷被称为BUG。
为了有效地管理和解决BUG，提高软件质量，需要建立一套完善的BUG管理规范。
二、BUG管理流程1. BUG的发现- BUG可以通过测试、用户反馈、代码审查等方式被发现。
- 发现BUG的人员应及时记录并详细描述BUG的现象、复现步骤、影响范围等信息。
2. BUG的分类与优先级划分- BUG应根据其严重程度和影响范围进行分类和优先级划分，以便开辟人员能够有针对性地解决问题。
- 常见的分类包括功能性BUG、性能问题、界面问题等，优先级划分可以分为高、中、低三个级别。
3. BUG的确认与分配- 由开辟人员对BUG进行确认，确保BUG的存在和可复现性。
- 确认后，开辟人员应根据BUG的分类和优先级进行分配，分配给相应的开辟人员进行解决。
4. BUG的解决- 开辟人员应根据BUG的描述和复现步骤进行定位和解决。
- 在解决BUG的过程中，应编写相应的测试用例，以确保解决BUG的同时不引入新的问题。
- 解决完成后，应及时通知相关人员进行验证。
5. BUG的验证与关闭- 验证人员应根据开辟人员提供的解决方案和测试用例进行验证，确保BUG已经被解决。
- 验证通过后，验证人员应将BUG标记为已解决，并关闭该BUG。
- 如果验证不通过，应及时反馈给开辟人员，开辟人员重新解决并进行验证。
6. BUG的统计与分析- 对已解决和已关闭的BUG进行统计和分析，以便发现问题的病根和改进软件开辟过程。
- 统计和分析的内容可以包括BUG的数量、解决周期、解决率等。
三、BUG管理工具为了更好地管理和跟踪BUG，可以使用专门的BUG管理工具。
常见的BUG管理工具有JIRA、Bugzilla、禅道等。
这些工具可以匡助团队成员更好地协作、记录和解决BUG。
四、团队协作与沟通在BUG管理过程中，团队成员之间的协作与沟通非常重要。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
项目5测试中的BUG管理项目简介软件测试人员的职责是找出软件系统中存在的各种缺陷，以及跟踪处理这些缺陷。
从测试管理的角度来讲，如何有效管理发现Bug将直接影响软件的质量与工作效率，本项目将介绍在测试工作中Bug管理的流程，和两种有效的Bug管理工具。
实施模块1.Bugizilla工具的使用。
2.Test Director工具的使用。
能力目标1.了解软件测试中是管理Bug的一般流程。
2.了解Bugizilla工具的配置，工作原理及简单使用。
3.了解Test Director工具的配置，工作原理及简单使用。
模块1 Bugizilla工具的使用软件BUG管理系统功能有多有少。
但最少要管理以下几种信息：●如何重复软件BUG的详细步骤●正常情况（无BUG）应是怎样●现在情况（有BUG）又是怎样●谁来负责修补BUG●问题有没有解决Bugzilla是Mozilla公司向我们提供的一个开源的免费缺陷跟踪工具。
作为一个产品缺陷的记录及跟踪工具，它能够为你建立一个完善的Bug跟踪体系，包括报告Bug、查询Bug 记录并产生报表、处理解决、管理员系统初始化和设置四部分。
在Bugizilla中，Bug的管理流程如图5-1：图5-1任务1：Bugzilla操作1、用户登录及设置1.1用户登录<1>用户输入服务器地址，如：http://192.168.1.9/cgi-bin/bugs/index.cgi。
<2>进入主页面后，点击【Log in to an existing account】，再点击【login in】进入。
<3>进入注册页面，输入用户名和密码即可登录。
用户名为Email 地址，初始密码为用户名缩写。
登录后自动进入查询页面。
<4>如忘记密码，输入用户名,点击【submit request】，根据收到的邮件进行重新设置。
1.2 修改密码及设置<1>Login登录后，【Edit prefs】->【accout settings】进行密码修改。
<2>【Edit prefs】->【email settings】进行邮件设置。
<3>【Edit prefs】-> 【permissions】进行权限查询图5-22、Bug的处理过程2.1 报告Bug2.1.1测试人员报告Bug<1>请先进行查询，确认要提交的bug报告不会在原有纪录中存在，若已经存在，不要提交，若有什么建议，可在原有纪录中增加注释，告知其属主，让bug的属主看到这个而自己去修改。
<2>若Bug不存在，创建一份有效的bug报告后进行提交。
<3>操作：点击New，选择产品后，填写下表。
<4>填表注意：Assigned to: 为空则默认为设定的owner, 也可手工制定。
CC: 可为多人，需用"，"隔开。
Desription中要详细说明下列情况：1）发现问题的步骤2）执行上述步骤后出现的情况3）期望应出现的正确结果选择group设置限定此bug对组的权限，若为空，则为公开。
<5>操作结果：Bug状态（status）可以选择Initial state 为New或Unconfirmed。
系统将自动通过Email通知项目组长或直接通知开发者。
<6>帮助：Bug writing guidelines图5-32.1.2 开发人员报告Bug.<1>具体方法同测试人员报告。
<2>区别：Bug初始状态将自动设为Unconfirmed，待测试人员确定后变为“New"。
2.2 Bug的不同处理情况2.2.1 Bug的属主(owner) 处理问题后，提出解决意见及方法。
<1>给出解决方法并填写Additional Comments，还可创建附件（如：更改提交单）<2>具体操作（填表项如下）<3>填表注意：FIXED 描述的问题已经修改INVALID 描述的问题不是一个bug（输入错误后，通过此项来取消）WONTFIX 描述的问题将永远不会被修复。
LATER 描述的问题将不会在产品的这个版本中解决.DUPLICATE 描述的问题是一个存在的bug的复件。
WORKSFORME 所有要重新产生这个bug的企图是无效的。
如果有更多的信息出现，请重新分配这个bug，而现在只把它归档。
2.2.2 项目组长或开发者重新指定Bug的属主。
（owner）<1>为此bug不属于自己的范围，可置为Assigned,等待测试人员重新指定。
<2>为此bug不属于自己的范围，但知道谁应该负责，直接输入被指定人的Email，进行Ressigned。
<3>操作：（可选项如下）* Accept bug (change status to ASSIGNED)* Reassign bug to* Reassign bug to owner and QA contact of selected component<4>操作结果：此时bug状态又变为New，此bug的owner变为被指定的人。
图5-42.2.3测试人员验证已修改的Bug.<1>测试人员查询开发者已修改的bug，即Status为"Resolved",Resolution为"Fixed".进行重新测试。
（可创建test case附件）<2>经验证无误后，修改Resolution为VERIFIED。
待整个产品发布后，修改为CLOSED。
若还有问题，REOPENED，状态重新变为“New"，并发邮件通知。
<3>具体操作（可选择项）a. Leave as RESOLVED FIXEDb. Mark bug as VERIFIEDc. Mark bug as CLOSEDd. Reopen bug2.2.4 Bug报告者（reporter）或其他有权限的用户修改及补充Bug●可以修改Bug的各项内容。
●可以增加建立附件，增加了相关性, 并加一些评论来解释你正在做些什么和你为什么做。
●操作结果：每当一些人修改了bug报告或加了一个评论，他们将会被加到CC列表中，bug 报告中的改变会显在要发给属主、写报告者和CC列表中的人的电子邮件中。
2.2.5测试人员确认开发人员报告的Bug是否存在.●查询状态为“Unconfirmed"的Bug,●测试人员对开发人员提交的Bug进行确认，确认Bug存在。
●具体操作：选中“Confirm bug(change status to New)"后，进行commit.●操作结果：状态变为“New".2.3 查询Bug1．直接输入Bug Id，点击find 查询。
可以查看Bug的活动纪录。
2．点击Query，输入条件进行查询。
3．查询Bug活动的历史4．产生报表。
5．帮助：点击Clue.图5-53、关于权限的说明1．组内成员对bug具有查询的权利,但不能进行修改。
2．Bug的owner 和reporter 具有修改的权利。
3．具有特殊权限的用户具有修改的权利。
4、BUG处理流程1．测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，通过Email通知项目组长或直接通知开发者。
2．项目组长根据具体情况，重新reassigned分配给bug所属的开发者。
3．开发者收到Email信息后，判断是否为自己的修改范围.1）若不是,重新reassigned分配给项目组长或应该分配的开发者。
2）若是，进行处理，resolved并给出解决方法。
（可创建补丁附件及补充说明）4．测试人员查询开发者已修改的bug，进行重新测试。
（可创建test case附件）1）经验证无误后，修改状态为VERIFIED。
待整个产品发布后，修改为CLOSED。
2）还有问题，REOPENED，状态重新变为“Ne w"，并发邮件通知。
5．如果这个BUG一周内一直没被处理过。
Bugzilla就会一直用email骚扰它的属主，直到采取行动。
模块二 TestDirector工具的使用TestDirector是MI（Mercury Interactive）公司一个测试管理工具，是业界第一个基于Web 的测试管理系统, TestDirector 的出错管理直接贯穿作用于测试的全过程，以提供管理系统终端-终端的出错跟踪—从最初的问题发现到修改错误再到检验修改结果。
由于同一项目组中的成员经常分布于不同的地方，TestDirector 基于浏览器的特征，使出错管理能让多个用户何时何地都可通过Web 查询出错跟踪情况。
利用出错管理，测试人员只需进入一个URL ，就可汇报和更新错误，过滤整理错误列表并作趋势分析。
在进入一个出错案例前，测试人员还可自动执行一次错误数据库的搜寻，确定是否已有类似的案例记录。
这一查寻功能可避免重复劳动。
任务1：记录缺陷任务的目的是让用户知道怎么使用TestDirecotr 来管理软件缺陷（bug）：以下为记录缺陷的工作流程：步骤一：添加缺陷1．添加缺陷：如图为记录缺陷的主界面：图5-6点击“Add Defect”按钮，图5-7点击“Submit”按钮，提交这条bug。
如果想填写bug信息错误，点击“Clear”按钮，可以清除已经填写的bug信息。
点击“文本附件”按钮，可以添加文件类型的附件。
点击“Web附件”按钮，可以添加web类型的附件。
点击“拍照”按钮，可以抓图片，并且作为附件，记录下对应的测试环境的信息。
图5-8图5-92．比较缺陷再填写完bug 信息后，有必要进行bug比较，点击“Find Similar Defects”按钮，查找是否存在相同的bug，如果有相似的bug，会弹出如图的界面。
图5-10如果没有相同的bug，会有如图的提示：图5-11步骤二：检查新缺陷开发负责人检查是否有new(新)的缺陷，如果的确是bug的话，将它的状态修改为open（开放），如果发现这条bug提重复或者不是bug时，将它的状态改为closed（关闭）或者Rejected （拒绝），注Rejected状态的bug可以在bug评审会上确定是closed（关闭）还是open（开放）。
如果开发人员Rejected bug的原因是bug 描述不清，请在回执中注明；如果是其他的原因，也请在回执中注明清楚。
步骤三：修改开放缺陷开发人员修改open状态的bug，修改完成后将bug状态改为fixed（已修复）状态。